Just got two new WU's downloaded and that's with "connect to server" at 3.5. That should be more than high enough for most normal conditions and was JUST enough for me to get thru the Christmas outage without going idle. Looks like if you crunch WCG under BOINC, you want to go straight to 5.8.9 and skip 5.8.8. In the seven hours I've been running it, my DCF has already dropped to 1.269735. The 5.8 level is clearly a major change from the 5.4 level. There will probably be other differences that will show up soon. 5.8.9 has run fine so far if you want to go ahead and download it but you can wait until it's "gold" too if you prefer.

:(, the new BOINC sucks. I've switched to 5.8.8 and then there's 5.8.9. Come on! Why can't the new BOINC client just fetch work like 5.4.11?

cio_redulla

I am using 5.8.8 and I have no problem so far. I wonder if it is because my cache is small 0.1 day and am running two Boinc projects.

Well, if the purpose of high cache-setting is to handle Unexpected Outages, it's always been a bad idea to set cache-size larger than 1/2 deadline.

Why?

Because when project goes down, all work in your buffer is generally N days old already. Meaning, can setup this table:

Cache-size - How long till deadline with 7-days deadline
0.1 days - 6.9 days => handle 0.1 days outage.
1 day - 6 days => handle 1 days outage.
2 days - 5 days => handle 2 days outage.
3 days - 4 days => handle 3 days outage.
3.5 days - 3.5 days => handle 3.5 days outage.
4 days - 3 days => handle 3 days outage.
5 days - 2 days => handle 2 days outage.
6 days - 1 day => handle 1 day outage.

Granted, WCG gives you an extra 2 days to return work past the deadline, but AFAIK no other projects does this, and in some even 1 second after deadline means you've just wasted whatever cpu-time used on this wu.

So, generally, with a 7-day deadline, both 1-day cache-setting and 6 days cache-setting can handle 1 day unexpected outage. The 5 extra days with the larger cache-size is generally just wasted cpu-cycles that won't be used for anything.


Setting up a similar table for v5.8.xx, you get, with default 1 hour switch-interwall:
Cache-size set by user - actual cache-size in project with 7-days deadline:
0.1 days (BOINC default) - 0.1 days.
0.3 days (WCG default) - 0.3 days.
1 day - 1 day
2 days - 2 days
2.5 days - 2.5 days
3 days - 2.96 days
3.5 days - 2.46 days
4 days - 1.96 days
5 days - 0.96 days
6 days - zero days.

To have a little extra safety, uses 90% of computational deadline, meaning in practice the max cache-size is 2.82 days.

If atleast 1 wu in a project is in deadline-trouble, all work-requests to this project is blocked, until not in deadline-trouble any longer, or atleast 1 cpu is idle.

If you're attached to other projects they can continue give you more work.


Basically, v5.8.xx just enforces the fact it's a bad idea to set cache-size larger than 1/2 the deadline, but adds an extra safety-margin on top of this so it's a little less than 1/2 the deadline.

For that Cio, you need to study the new Work Fetch Policy or WFP in depth. It's much smarter, but may still be needing some tweaks to not out-smart itself. Ingleside posted some logic why it gets worse the larger the buffer which has an in-build safety %.

http://www.worldcommunitygrid.org/forums/wcg/viewthread?thread=11582#86205

I've got it on 2.5 days which even in the worst scenario has never been that long on the WCG downtime front.