The problem is as mycroft described - the workunits have a large range of variation in how long they take that cannot be determined ahead of time.

The estimate is provided to BOINC in terms of the estimated number of floating point operations it will take to complete the workunit. BOINC then uses that with what the benchmarks determine the floating point operations per second are for that machine in order to determine how long it will take the workunit to run (at least initially and when the work is handed out).

The average floating ops of the returned results (based on around 147,000 results returned) has been:

10,046,656,745,240

The estimate that we are providing is:

12,500,000,000,000

So we are estimating about 25% higher then they are taking - on average.

However - this doesn't do you any good if you get two huge workunits in a row.

If we modify this so that it is 50% or 100% higher then the average then there will be computers that have requested X amount of work that will run out of work before the time that they specified which would leave them idle if they only have intermitant access to request new work.

The best advice that I can offer is that you go and abort the workunits for World Community Grid that you have not yet started working on. This will cause the server to immediately re-issue that work to someone else and cost you anything in terms of runtime. I would also suggest that if this is a computer that is always or nearly always connected to the internet and almost always is able to download new work, then you should go to the device profile for that work and change the setting "Connect to network about every" to something low like 0.05 or 0.1. This will minimize the number of workunits cached and should elminate the problem.