I'm having a bit of a similar problem with controlling how many WUs my BOINC client has at once.

I don't want to limit when/how often it can connect...it's always on-line, provided that our DSL is up, and it should always be able to connect. However, I've noticed in my logs that it sometimes has problems connecting or gets blown off by the server, and ends up sitting around for a while without any WUs to process. Looking at my Results' Status page, I can see several significant gaps, for example, I returned WU EP275_16 on 05/04/2006 at 04:23:31, but my next WU (faah0451_ d017cb961_ x1hpv_ 00) downloaded three hours later, at 7:23:37.

It'd be nice to have a little independant control over how many WUs the client downloads...I'd like to have two at all times, and sometimes three, so that if it got blown off requesting another WU, it would still be crunching...instead of the current one WU most of the time, and two WUs when the current one is close to finishing. Since I average 5:36:46 per WU, I'd have been more than half-way through another WU if I could have eliminated that three-hour gap by keeping an extra WU in my queue. In fact, I'd have finished a short one already...makes me think I might need three at all times to be safe.

Verbatim,

The only way to control the number of WUs in your queue is to change the "Connect every n days" interval in your BOINC setup. The default is .1 and if that's what you are using then try boosting it up a bit.

I have found that it's best to tweak the value by a very small amount (no more than +/- .2) then click the Update button. Wait for at least 1 WU to process (2 is better) and then re-evaluate.

If you change the Connect to Server value by large amounts then you may get wild swings in how many units you queue up on your end. Tweak it up slowly else you'll go nuts adjusting it up and down as you attempt to bring the wild swings under control.

Sekerob,

Only the code cutters know for sure but based on my observations of how it behaves I think it tries to draw work volume not only on the basis of the last result's return time but several other factors as well. I've noticed that if I let a machine run uninterrupted for several days, 24/7, projected completion times eventually get fairly close to actual completion times and the WU backlog is darn close to what I have in my Contact Server Every n Days setting. The closer BOINC get to having all the CPU time the better it estimates.

However, if I interrupt a WU and turn the machine off (or just shutdown BOINC) for an extended period, say 10 hours, when I start BOINC again the projected completion time for the interrupted WU and any other WUs in the queue will be much higher immediately after restart but will eventually come to reflect reality. Also, during the time it takes to readjust its projections, it seems hesitant to download new WUs. That seems prudent for I may decide to turn the machine off again or suspend all activities for that project and go crunch for a different project for a while.

The algorithim for projecting completion time and deciding when to download additional WUs seems to be very complicated and I commend the coders for their implementation of it for it seems to work very well over the long run. In the short term it can look out to lunch but ... oh well, the long term is what matters.

Dagorath, i translated what you said and compared that to what i thought i said clearly......essentially we concluded the same. Since i switched on BOINC 17.Apr.06 the BOINC machine has been running 24/7. Now it got it figured out reasonably well i.e. as i said, 68 hours wall clock is 48 hours CPU time (WCG records for me an average CPU daily of 16.1, slightly rising since BOINC.

Funny thing is, occasionally my machine or anyone's machine seems to like one WU better than the other, so agree with DiDactylos too....it remains a potshot. I wonder if the WU's are allocated on a semi AI basis....heavy's going to the hd-crunchers?

One very obscure phenomena: If you leave the GUI open i.e. not minimised to tray, the WU's go faster (more CPU clockticks seemingly going to BOINC, or rather maybe, more persistently holding on). For sure the tray info does not get updated, when minimised to tray. Does this status provoke black hole / extra idle/unused ticks?

PS on the latter, does not matter if sitting behind some other open window, same experience, so i keep GUI open on the work tab. If its perception, fine, i'm a believer......

i anticipated that question.....1 hour minimised to tray v 1 hour open / on top. Repeated several time. In all cases did not touch the machine.......i'll for sure keep it open. Probably would have todo it over longer periods as some birdy told me that a WU can have sections that fold less easy than others, but if 1 hour minimised to tray progresses the WU by 11% and expanded 13%, repeatedly, i'll discount the heavy section theorem.

PS i killed all scheduled processes! In connection with the GUI freezing issue, i suspect something not kosher in the links between the docker, boinc.exe and boincmgr.exe... wild stab, i never got beyond BASIC, COBOL and Fortran.