Kremmen,

I will have to take a look at this. The mechanism that determines if a computer is 'reliable' checks the following:

1) Average turnaround time for a workunit is 24 hours
2) Max error rate is less then 1%

Error rate is a measurement of the recent history of valid results versus invalid results.

The goal here is to make sure that the workunit is assigned to a computer that will return the result quickly and correctly.


Once the computer has been determined to be reliable and it is matched with a workunit that needs a reliable computer to run it then the deadline for the workunit is set at 20% of the original deadline or twice the estimated wall clock time it will take for the workunit to complete. The estimated wall clock time is based on a function that uses the measurements of % time BOINC is running, % of time the client is on and estimated cpu duration (including it being modified by the duration correction factor).

This check for estimated wall clock time is intended to prevent the workunit from being assigned a unreasonable deadline on your computer.

Well, it didn't work this time. The machine is extremely reliable and, when accepting work from WCG, usually does nothing else. At the outset, the estimate by boinc_cmd of how long the WU would take was 32 hours. However, there's something screwy about the estimates on this job, since that kept dropping rapidly and probably would have really been about 24 hours. (... had an unfortunate circumstance on the machine, whereby insufficient disk was available, caused the checkpoint file not to be able to be written and subsequent error. I've put another drive in it with 10GB just for WCG, so it won't run into contention again.)

Right you are. on_frac is 0. However, active_frac=0.999849 and cpu_efficiency=0.971315 . Maybe the server could use active_frac when on_frac is somehow zero?

Looking at my backups, on_frac is always 0 on that machine. Every other machine has a sensible value for it. They are all running 5.8.15.

edit: last_update was an enormous number. I don't know how it got that way, but maybe that was part of the problem.

P.s., when I go to that web site
https://secure.worldcommunitygrid.org/reg/ms/viewDownloadBoinc.do
they only offer the version I already have for Linux.

As of yet there is no 5.10.x recommended version by WCG nor one of Berkeley. If intend on at least being able to get AC@H work, if available, visit the tweak instruction to set one time the <bwdown>100000.000000</bwdown> value in the client_state.xml (prior exiting of BOINC required).