Hi@all,

I think there is a bug in the calculation of the "overcommitted" value.
At the moment I set the client to download 3 days.
In the beginning it downloads about only approximately 1 day (from Seti@home).
After this I´ve got all the time :
08.10.2006 19:54:58||Using earliest-deadline-first scheduling because computer is overcommitted.
08.10.2006 19:54:58||Suspending work fetch because computer is overcommitted.

But now I had only 11 WUs with 34 Mins each left (374 mins or 6 - 7 hours to work).
When I try a higher value for "work_buf_min_days" like 4 or higher ... I always got the same error, until only one or two WUs are left.
Then the client loads again some WUs, but also not the exact time from the server.

If you set the value for "work_buf_min_days" to 0.2 or similiar then the message with the overcommitment is gone, but this solves nothing ... there are still to less WUs in the queue.

So could somebody fix this, please ?
Client 5.4.11

The same error got also a report here :
http://boinc.berkeley.edu/dev/forum_thread.php?id=1094
<quote>but it seems to me (Only my humble opinion as a programmer, didn't see the code, so maybe i'm wrong) that the calculation method for guessing the time of completing each project has something wrong.</quote>

CYA
Akermit

---

Hmmm ...
Here are some possible tweaks :

1. Show estimated calculated time of all WUs in the client
I think the calculation is absolutly wrong, so this time will show a great difference between the "Result duration correction factor --> Estimated Time" and the "I´m soooo overcommitted Time"

2. Put in a switch that gives the user the ability to choose for the WUs ... :
The user could choose between FDFO (First Date First Out) or compute as they come.
Mean the nearest date will be computed first with FDFO.
But in the same time the overcommitment rule isn´t active.
And this must be different for each project.
e.g. I´m running Climate Prediction, too ... when FDFO is applied to all projects at the same amount, CPDN will never run (endtime in one year).

3. Make it possible to change parameters without manual editing global_prefs.xml
IMHO it would be VERY fine, when this could be changed in / by the client.
Also it would nicer when the changes apply immediately without a restart.


CYA
Akermit

---

guessing the overcommit shouldn't be too difficoult, after a first sight i'd say that a method could be for each active WU:

1) time to complete WU +
2) minor time between time to complete all the other active WUs and time to complete WU(1) +
(if we have to ask for a new WU)
3) minor time between average time to complete new WU or number of seconds we're asking for and time to complete WU(1)

this sum should be divided by the time of active calculation a day (from hour to hour in the preferences page) and multiplied by 24 hours

Best Regards
BadWolf

P.S. i'd add a flag for weekends... often PCs in work places are turned off in the weekends...

---