Posts by mikus

1) Message boards : Web interfaces : logging off (Message 11415)
Posted 30 Jun 2007 by mikus
Post:
2. With FF set to "delete cookies when FF closes", if I login to Malaria with "stay logged in" checked then close FF before logging out of Malaria then I am required to login again if I want to access my Malaria account 1 minute later, as it should be. Mikus, I think you are saying it does not work that way for you?

For me, too, it works the way you have described here. I had written earlier:
When I closed my browser session and started a new one, and tried some of the four "misbehaving" websites, they required a 'new' logon. So wiping out cookies (by closing the browser session) did get rid of the "misbehaving".


p.s. Two other "misbehaving" projects are Rosetta and Predictor.
.
2) Message boards : Web interfaces : logging off (Message 11387)
Posted 29 Jun 2007 by mikus
Post:
I'm not sure what's going on. If you let me know what version of FF (I have 2.0.0.4 on Vista, XP and Ubuntu) and tell me exactly what you have set under privacy and security in options, I'll try to replicate.

While you're at it, you might want to think about opening a ticket in Trac.


I use FF 2.0.0.4 on all the systems I have installed. Looking at the settings, none of them seem exceptional to me [if something is not mentioned, it is not checked in options]. Privacy panel: History - remember visited pages for 2 days; Cookies - accept cookies from all sites (no exceptions), and keep them until I close FF; Private Data - always clear upon close: Saved Form, Cache, Cookies, Saved Passwords, Authenticated Sessions. Security panel: Warn when sites try to install add-ons (no exceptions); Warning messages - if viewing page with low-grade encryption.


--------

In my original post I said: "Don't get me wrong - I'm not complaining." I was __not__ asking for help. My reason for posting was to alert others that they too might possibly get this kind of response to log-off. If they see it, and have complaints, let them open a ticket.


I myself question the procedure of "first ask the reporter for details about his system". [I once had a __software__ APAR rejected by IBM on the grounds that "This problem was reported on an EISA system. We do not have an EISA system on which to reproduce this !!!] To my mind, most problems worth looking at will have "replicated themselves". If a problem shows up only within a restricted environment, there might be better fish to fry.
.
3) Message boards : Web interfaces : logging off (Message 11363)
Posted 28 Jun 2007 by mikus
Post:
Which projects are showing this behavior?

I'm quite paranoid when it comes to cookies. I use FF, and have taken the technical steps available to me to ensure that, while cookies are accepted by the browser (and kept in memory), they will __not__ get written out to disk when the browser session gets closed. Thus I do *not* keep persistent cookies.


I went through the eight projects I had attached to my "big" system, and performed a log-in followed by a log-out for each:

Four projects behaved "properly" (that is, I loggged off and stayed logged off) --
Docking, ABC, LHC, Einstein

Four projects gave me the response "Unable to handle request" --
Leiden, Malaria, QMC, Simap


Further than that, as far as I was concerned there was a bug with the websites of the four projects which told me they were unable to handle my logoff request -- When (within a reasonable period of time) I again tried to load the page for my account -- it *worked*. Meaning that when they said "unable" they meant it -- as far as those websites were concerned, I *did* remain logged in.

[When I closed my browser session and started a new one, and tried some of the four "misbehaving" websites, they required a 'new' logon. So wiping out cookies (by closing the browser session) did get rid of the "misbehaving".
.
4) Message boards : Web interfaces : logging off (Message 11316)
Posted 27 Jun 2007 by mikus
Post:
I am not permanently connected to the internet. When I log in to a project's website, I usually uncheck the 'Stay logged in on this computer' box - I'm afraid that I will forget to logoff, and that when I disconnect the dynamic IP address I was using might be left 'privileged' in regard to accessing that website - I figure I'd want the website to "time out" if I forget.

Lately, more and more project websites are responding 'Unable to handle request - not logged in' when I *do* perform a logout. Don't get me wrong - I'm not complaining. It just seems odd that when I explicitly request that the 'privileged' (i.e., logged in) state be ended, the site grumbles.
5) Message boards : BOINC Manager : On Linux, what font does the BOINC Manager use ? (Message 5006)
Posted 13 Jul 2006 by mikus
Post:
Running the 5.2.14 Linux BOINC Manager on Ubuntu. On Breezy (the previous operating system version) I could easily read the text displayed within the Manager's tab panels. Without reformatting my /home partition, I installed Dapper (the most recent release of the operating system). Now the text displayed within the Manager's tab panels is very difficult to read -- the text characters are all scrunched against each other horizontally.

I've tried all the avaiable gnome-configuration font settings -- none change how the text within the Manager's tab panels is being displayed. What tells BOINC Manager (on Linux) what font to use ? [I want to change the font to something I can read.]
.
6) Message boards : BOINC Manager : changing the queue size (Message 4803)
Posted 21 Jun 2006 by mikus
Post:
Just think if you have 10 computers, not all in your own room, and you have to update the cache on each of them by hand. Wouldn't you want it to be centralized and downloadable automatically by the client?

Note that I am normally running with network activity suspended, so I have to intervene anyway for each to be able to contact the server(s). Speaking just for myself, the computers in the second room would likely not have the same capabilities (or frequency of visits by me) as the computers in the first room. In which case I probably would want to specify a different queue size for the computers in the second room than for the computers in the first room.
.
7) Message boards : BOINC Manager : changing the queue size (Message 4800)
Posted 20 Jun 2006 by mikus
Post:
I run off-line (network activity suspended). I wanted (on 5.4.9) to reduce the queue size (for new downloads) from 6 days to 5 days. Having changed the parameter at the project's webpage, what I did at the client system was to click on 'update' as soon as I had activated the network. That was too late - the client had already requested work (still using the previous queue size that I no longer wanted).

It was pointed out to me that the way I could make *sure* that the new size was used was to, at boincmgr: (1) mark the projects "no new work"; (2) activate the network; (3) request an "update" for the project whose webpage parameter I changed; (4) allow the projects to "fetch new work" only after that 'update' had been processed by the client. Sounds cumbersome.

I think it would be much simpler for the user if the 'queue size' could be set at boincmgr (NOT at the webpage). Then the client would already know the new value before it made contact with the server, and would not have to be manually restrained to prevent it from requesting work before the current kept-at-the-server value could be communicated to it.
.
8) Message boards : BOINC client : interaction between project scheduling and downloading (Message 4741)
Posted 16 Jun 2006 by mikus
Post:
Until recently I've been running only one BOINC project at a time on my computer (BOINC client 5.2.14). Now I'm attached to two projects. The one project has WUs of four to twelve hours; the other has WUs of one hour (but has more data to be downloaded for each WU). I normally run off-line, meaning that when I activate my suspended network connection, there is usually quite a lot of data to be uploaded and downloaded.

I'm on a dial-up line, so the larger downloads (of the data for each WU) take 8 or more minutes each. I was AMUSED to see the behavior of the BOINC client. It is running the WU for the one project. Then a download finishes, making an additional WU "ready". The BOINC client pausses the WU that was running, and runs the WU for the other project. Then a download finishes, making an additional WU "ready". The BOINC client pauses the WU that was running, and resumes the WU for the first project. Then a download finishes, making an additional WU "ready". The BOINC client pauses the WU that was running, and resumes the WU for the second project. Then a download finishes ...

What I am seeing is a "ping-ponging" between the WUs of the two projects, every time a completed download "readies" yet another WU on my not-yet-crunched queue (which I've defined to be several days long). The interval between "ping-pongs" is how long it takes for the next data download (which readies a WU) to complete, __not__ the "time between project switches" as defined at the server website.
.
9) Message boards : BOINC client : data transfer overlap ? (Message 4709)
Posted 13 Jun 2006 by mikus
Post:
I'm a dial-up user. For the first time ever, I have the same computer attached to two projects. A while after I activated (after suspending for several days) that computer's network activity, there was a period when the BOINC client was downloading new work for one project while still uploading results from the other project.

What I noticed was that on this occasion, the download speed (instantaneous byte transfer rate) was reported (by boincmgr) as very SMALL while the upload speed was reported in the range I expected. As far as I know, my communications line is set up for full-duplex -- meaning that it ought to be capable of "normal" byte transfer speeds in both the "up" direction and the "down" direction -- simultaneously.

Was it the BOINC client that "throttled" my download speed in that situation ?
.
10) Message boards : BOINC client : wish for automatic 'parameter download' on request for work (Message 4647)
Posted 4 Jun 2006 by mikus
Post:
You could click on "No new work", then click on Update.
That should get the changes sorted out.
Then click on "Allow new work".

Thanks for the tip.
.
11) Message boards : BOINC client : wish for automatic 'parameter download' on request for work (Message 4641)
Posted 3 Jun 2006 by mikus
Post:
Running 5.4.9 on an off-line Linux system. Had occasion to *reduce* the queue size (time between connects) parameter at the website. When I next (at the client) UN-suspended network activity, the client immediately asked for more work, based on the *previous* queue size value it knew about. (I manually clicked on 'update', but by then the server had already received the request for more work.)

What I'd like to see is for the client, in its initial RPC requesting work, to "pass along" the queue size value on which that work request was based. __IF__ the server finds that *its* 'queue size' value is different, the server would ignore that initial request for work, but would respond with the NEW 'queue size' value. The client would then recalculate its work request, and submit it anew. (Now the request would be accepted by the server, since the 'queue size' value it "passed along" was current.)
.
12) Message boards : BOINC client : too much preemption (Message 4473)
Posted 25 May 2006 by mikus
Post:
Running off-line with 5.4.9. Am attached to just a single BOINC project. Have a large "queue size".

While the client was crunching a 14-day-deadline WU, I connected to the server. The client requested some work and uploaded some results; two 7-day-deadline WUs were downloaded (including the files they depended upon). When one of the new WUs finished downloading (including its files) the client suspended the 14-day-deadline WU and started crunching the new 7-day-deadline WU. I have no problem with that. [Note: the WU it was now working on was shown last in the "tasks" panel in boincmgr.]

BUT when files finished downloading for the __other__ 7-day-deadline WU, the client SUSPENDED the 7-day-deadline WU it was now crunching, and started to crunch the other 7-day-deadline WU (the one whose files were last to finish downloading, but which was listed next-to-last in the "tasks" panel in boincmgr). That made TWO WUs now "suspended" for that project.

Since both newly downloaded WUs resulted from the same request for work, in my mind BOTH 7-day-deadline WUs ought to have had the __same__ expiration date. [To the accuracy shown by the boincmgr display field, both WUs indeed have the same expiration date/time!]

Let me suggest that it is INEFFICIENT to suspend one WU in order to initiate work on its TWIN. Before pre-empting an already started WU, the BOINC client ought to verify that the deadline for the WU it proposes to run instead is visibly __sooner__.
.
13) Message boards : Server programs : Result duration correction factor ? (Message 4143)
Posted 30 Apr 2006 by mikus
Post:
The normal Duration Correcion Factor in BOINC, checks how long results on your computer take. Since no result is sent out with a correct wall-clock time to what your computer does to calculate them, DCF recalculates per result how long they take.

Although, with the new upcoming 5.4.x (we hope .7) version of BOINC, this may go out the window, as I am running an optimized Einstein science app and I have a DCF of 0.24 there. Go figure. ;)

Check here what it should do.


Thank you. I had already viewed the wiki article before posting.

Neither it, nor what you write, explains to me WHY the calculated 'result duration correction factor' was SO HIGH for my computer. According to the wiki description, if my benchmark number were "correct", a 'result duration correction factor' of 4.0 means that work on my computer was estimated to take ONE QUARTER of the time it actually took. Looking at the results of similar work reported by other participants, NO ONE finished work units 75% faster than me - the best I ever saw (from a much more powerful computer) was 60% faster in elapsed time.

That raises the question of how misleading was my benchmark value. With the optimized 5.2.14 client, the BOINC benchmark (see the wiki) reported floating point operations value was 2226. With a 5.4.7 client, that value was 1027. To me, that difference demonstrates the "Linux penalty" built in to the non-optimized BOINC client. [I __realize__ that the ACTUAL performance is determined by the project application run on the client computer, and is INDEPENDENT of the value reported by the BOINC benchmark.] My point is that if I had been running with the un-optimized BOINC client, the calculated 'result duration correction factor' would still have been inappropriately HIGH (e.g., 1027/2226 * 4 = 1.8).

Nothing said in the wiki contradicts my concern that it was the TOO HIGH 'result duration correction factor' that prevented the server from downloading enough work to fill my "time between connects" specified queue size. If this is what happened, project administrators need to be WARNED that TOO HIGH a 'result duration correction factor' can __spoil__ the ("time between connects") queue size specified by users.
.
14) Message boards : Server programs : Result duration correction factor ? (Message 4131)
Posted 29 Apr 2006 by mikus
Post:
I run off-line, connect only every couple of days, and use only one BOINC project per computer. On the QMC project, I have specified the "time between connects" as four days, but lately it has been taking my computer no more than two days to complete all the work that gets downloaded to its ready queue. [This even when the client has asked for 345600 seconds of work!]

One thing I notice about my "statistics" for this project is that currently my 'result duration correction factor' is shown as 4.0. I *am* running an optimized client (Linux, 5.2.14) -- but I feel there is NO WAY that my actual time-to-complete could be FOUR times as long as the time estimated from the benchmark values. [In my opinion, the optimized client gives me benchmark values no more than twice as good as what an un-optimized client would show.]

Could it be this excessive 'result duration correction factor' that is causing less than four days worth of work to be downloaded to my computer's ready queue?

How come QMC is assigning my computer SO LARGE a 'result duration correction factor' in the first place?
.
15) Message boards : BOINC client : Is a heartbeat THAT critical ? (Message 4072)
Posted 25 Apr 2006 by mikus
Post:
Running off-line on Linux with a 5.2.14 optimized client. That computer had "gotten ahead" with its internal clock. I manually reset its clock several minutes backwards.

I was VERY surprised that my CPU monitor showed that the running BOINC application had STOPPED USING THE CPU !! After exactly that many minutes (i.e., when the internal clock had caught up to some sort of recorded time value), the BOINC application started again to use the CPU.

All I can figure out is that the client was waiting for the next successive (according to the wall clock) heartbeat.

What if I had need to set the computer's clock back by hours -- is it worth it to the BOINC logic to have the computer simply sit there idle for that much time ?
.
16) Message boards : BOINC client : benchmarks vs. real work units (Message 3962)
Posted 18 Apr 2006 by mikus
Post:
There is a proposal to replace the existing benchmark as run by the client with a 'standard BOINC computation' - to address "cheating" sometimes done by manual alteration of existing benchmark results. My recent experience suggests that even a 'standard BOINC computation' might not achieve "fairness" (i.e., same credit given for same work unit processed) among different hardware / software configurations.


I participate in several BOINC projects, but run only one such project per system. My 'rank' (i.e., total credit given) among project participants is not important to me. However, I had joined the Rosetta project using the "official" 5.2.13 Linux client. By a combination of circumstances, the same work unit was processed by me and by another participant, who had the SAME hardware as me, but who received four times as much credit for his work. [The suggested explanation was that he was using Windows and running an optimized client - therefore his benchmark figure was that much better.] When I joined the QMC project (different computer!), I deliberately used an "optimized" Linux 5.2.14 client. (This *does* give me an "unfair" advantage over unoptimized clients having a lower benchmark figure!)

My reason for posting here is that recently I saw "non-linear" QMC project computation times when comparing my system with someone elses. With a previous set of work units (I believe they ALL need a similar amount of work done) his system consistently took 11 hours to complete, but my system took 13 hours. With the latest set of work units, his system consistently took 33 hours to complete, but mine took 56 hours (which, combined with my higher benchmark figure, gave me MUCH more credit than him!).

Now, irrespective of the benchmark figure, in each system the ratio of benchmark figure (however calculated) to 'elapsed time to do the work' __ought__ to be consistent. Yet in his system (AMD X2, Windows) the newer work units took THREE times as long as the previous work units, whereas in my system (AMD Barton, Linux) they took more than FOUR times as long.

This experience leads me to believe that doing a 'credit per minute' calculation using a 'standard BOINC computation' would __still__ give non-linear results, depending on how_long/how_hard that computation took on a particular hardware / software system.
.
17) Message boards : BOINC client : Linux reinstallation: what to do with boinc ? (Message 3731)
Posted 31 Mar 2006 by mikus
Post:
I think you will loose your work. The project expected the same computer that DL the WU to send back the result.

I think that is worse than unfortunate.

I'm somebody who every month "tinkers" with at least one of my computers. This might involve replacement of the (Linux) kernel, or of the (OS) platform, or of the motherboard. And I do NOT have the patience to wait-to-upgrade until *all* the previously-downloaded BOINC WUs have been finished.

(The BOINC projects in which I participate all use long-duration WUs. And I'm on a dial-up line, connect only a couple times each week, and like to keep many days of work "queued up" at my computer - in case I don't get around to connecting regularly.)


I don't mind BOINC not accepting work that was *begun* on one computer and *finished* on 'another' computer. [But what if after three months into the execution of a CPDN WU that computer suffers a (non-disk) hardware failure? Ought not that WU (as reloaded from a disk backup) be allowed to finish on a _substitute_ computer, thereby NOT "losing" those three previous months of effort?]

But requiring that computer upgrades be deferred until all previously downloaded (but not yet processed) BOINC-project work has been completed and uploaded seems to me overly burdensome for someone voluntarily participating in a BOINC project.
.
18) Message boards : Web interfaces : request for exit timestamp in results record (Message 3512)
Posted 15 Mar 2006 by mikus
Post:
I do not keep information for a long time at the system running the client. The information kept at the server remains longer and is easier to access. The question has arisen as to whether a 'snapshot' of the "ready queue" at a client could be reconstructed "after-the-fact".

Let me suggest that a new "Exited" time stamp field be added to the 'Result' record, in addition to the existing "Created", "Sent", "Received", and "Deadline" time stamp fields in that record.

Its value would be stored by the client when it stores the result's "Exit status" value. Since the purpose would be to allow _sequencing_ the execution of the WUs at the client system, it would not matter if there was an offset between the time kept by the client system and the time kept by the server system.
.
19) Message boards : BOINC client : large cache size difficult with short-deadline WU (Message 3507)
Posted 15 Mar 2006 by mikus
Post:
I run off-line, except for occasional connects to the server. My cache size is currently specified as 6 days.

On Mar 12 I downloaded work, all of which would expire on Mar 26. On Mar 14 (running offline) my system had about 100 hours of work left in its "ready queue" for the project. The client went into 'earliest deadline first' scheduling mode.

Someone had posted: 'if a project deadline is less than double the cache size, the box will only run in EDF mode'. That's what seems to have happened here. (The hour on Mar 14, plus 12 days, amounted to more than the deadline.)

BUT the processing % currently allocated to the project would have completed the 100 hours still-to-do BEFORE Mar 20 !! I would have preferred the client's logic to be: "calculate when the last WU is estimated to complete; then (assuming the next report is not made for 6 days) will the result be reported in time?". In my case, the 100 hours still-to-do would have completed (at the project's allocated processing %) on Mar 19 !! EDF mode was *not* needed.


Let me suggest that the BOINC client have *two* specifiable values - one to limit the number of days of READY work to be kept at the client <ought to be __variable__ for different projects>, and the other to limit the number of days that COMPLETED work might be kept at the client <same for every project>. The first would govern the amount of work downloaded (I prefer to keep a sizeable queue, so as not to run out of work in case the server is down). The second would govern when EDF mode is entered (similar to today's "connect interval" - first the value would be subtracted from the deadline, then the threshold for EDF would be calculated backwards assuming 100% processing for the project).
.
20) Message boards : BOINC client : BOINC requests too much work if download is slow (Message 3238)
Posted 25 Feb 2006 by mikus
Post:
For a computer that is normally off-line, when a connection is made BOINC apparently looks at the queue of ready-to-run work units, and calculates how many seconds of new work to request from a project. So far so good.

Then, after an interval (e.g., 4 minutes), BOINC __again__ performs the same kind of calculation. IF, when it now looks at the ready-to-run queue, the previously requested work units *have* been downloaded, all is well. BUT in my case (I have a *slow* dial-up line) the download of the previously requested work has usually NOT COMPLETED. I see BOINC again requesting work, WITHOUT CONSIDERING how much work it had already scheduled to be downloaded.

The result for me (using BOINC 5.2.13 on Linux) is a series of ever-diminishing requests for work (at 4 minute intervals) while the download continues; the cumulative effect of these multiple requests is to fetch FAR MORE WORK than appropriate.

In fact, since I might not dial in for days, I had set my project's website preferences to give me a "cache size" (of queued-up work) of 6 days. When the project recently switched to work units with a time-to-expire of 7 days, the EXTRA work units caused to be downloaded by this BOINC problem ended up being wasted (so did all those hours my connection spent downloading them).


BOINC should issue a __single__ request for work, and should *NOT* re-request any more as long as there are ANY downloads not yet completed.
.


Next 20

Copyright © 2024 University of California.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.