Is this a common problem?

The to completion time for a workunit off CPDN is 480396:29:36 at the moment. Which is a bit to much...

The strange predictions started when I upgraded from 5.4.9 to 5.4.11.

See below for my common info.

Regards, Wim

07/01/2007 02:24:14||Starting BOINC client version 5.4.11 for windows_intelx86
07/01/2007 02:24:14||libcurl/7.15.3 OpenSSL/0.9.8a zlib/1.2.3
07/01/2007 02:24:14||Data directory: C:\\Program Files\\BOINC
07/01/2007 02:24:14||Processor: 2 GenuineIntel Intel(R) Pentium(R) 4 CPU 3.00GHz
07/01/2007 02:24:14||Memory: 1022.09 MB physical, 2.40 GB virtual
07/01/2007 02:24:14||Disk: 229.26 GB total, 18.41 GB free
..
<snip>
..
07/01/2007 02:24:15|climateprediction.net|Resuming task hadcm3ohe_0efx_05667055_0 using hadcm3 version 515
07/01/2007 02:24:17|SETI@home|Resuming task 06ja00ab.9181.7009.54816.3.94_2 using setiathome_enhanced version 515
07/01/2007 02:24:19||Using earliest-deadline-first scheduling because computer is overcommitted.
07/01/2007 02:24:19||Suspending work fetch because computer is overcommitted.

Yes, this is very common. Because of CPDN extremely long completion time and Boinc's conservative estimate it often causes it to enter panic mode. This is especially the case for slower computers and those not crunching full time. After CPDN has crunched for a while on its own, Boinc will return to round robin mode. As CPDN gets closer to finishing it will begin to repay the extra time it appropriated from the other projects and give back the extra time it took so as to maintain the resource share you have allocated.

The next version of Boinc as some more changes to the scheduler which hopefully will allow Boinc to handle a mix of very short and very long projects more gracefully while still guaranteeing that projects will report on time. This is a continuing struggle of conflicting interests that Boinc must deal with.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

And the cpdn deadlines aren't enforced ie even if a model completes well past its deadline, it will still be accepted as long as it trickles now and again. It looks as if the current cpdn models will be active until at least the end of 2007.

Setting the screensaver to None will speed up your workunits, and if you can choose to exit from boinc eg to turn off the computer, just after a 6-day model checkpoint, you won't waste time repeating calculations.

---

The strange predictions started when I upgraded from 5.4.9 to 5.4.11.

Adding to all the other advice given, what were the benchmarks for the computer? They don't show in your list, you snipped them.

---

Sorry about that, here it is:

07/01/2007 19:44:19||Suspending network activity - running CPU benchmarks
07/01/2007 19:44:21||Running CPU benchmarks
07/01/2007 19:45:20||Benchmark results:
07/01/2007 19:45:20|| Number of CPUs: 2
07/01/2007 19:45:20|| 1247 floating point MIPS (Whetstone) per CPU
07/01/2007 19:45:20|| 1526 integer MIPS (Dhrystone) per CPU
07/01/2007 19:45:20||Finished CPU benchmarks
07/01/2007 19:45:21||Resuming computation
07/01/2007 19:45:21||Rescheduling CPU: Resuming computation
07/01/2007 19:45:21||Resuming network activity

Regards,

Wim

07/01/2007 19:45:20|| Number of CPUs: 2
07/01/2007 19:45:20|| 1247 floating point MIPS (Whetstone) per CPU
07/01/2007 19:45:20|| 1526 integer MIPS (Dhrystone) per CPU

OK, that's normal.

Your CPU is recognized as a Hyperthreading one, so one which can do 2 results at the same time. Your BOINC recognizes it can do two at the same time.
Double those figures to get to the somewhat correct MIPS per CPU.

Do you only have one or do you have two CPDN results?

---

Do you only have one or do you have two CPDN results?

I've got one result at the moment, but I'm running Malariacontrol and Seti@home also. The 'to completion' time for Malariacontrol is also way off, 236:00:00 when it started a new workunit. The workunit will be finished however in slightly under one hour in reality. Seti@home has the same 'problem', 470:00:00, while it finishes in about 4 hours.

Regards,

Wim

OK, sounds like your Duration Correction Factor took a hit somewhere.

Can you check what your results are for that number on your accounts?
You generally find this number in the "Computers attached to this account" option.
Go to the host ID number and copy per project and paste here these entries:

% of time BOINC client is running
While BOINC running, % of time work is allowed
Average CPU efficiency
Result duration correction factor

(Kom je daar niet helemaal aan uit, vraag dan hoe en wat)

---

Go to the host ID number and copy per project and paste here these entries:

Oke, here it goes...

CPDN
99.4182% of time BOINC client is running
While BOINC running, 40.6571 % of time work is allowed
Average CPU efficiency 0.942442
Result duration correction factor 156.542116

MalariaControl.net
99.4182% of time BOINC client is running
While BOINC running, 40.6571 % of time work is allowed
Average CPU efficiency 0.94628
Result duration correction factor 107.257749

Seti@home
99.4182% of time BOINC client is running
While BOINC running, 40.6571 % of time work is allowed
Average CPU efficiency 0.931214
Result duration correction factor 97.41966

BURP
99.4182% of time BOINC client is running
While BOINC running, 40.6571 % of time work is allowed
Average CPU efficiency 0.94628
Result duration correction factor 428.433794

That's it.

I'm wondering now where that 40.6571% is comming from... Can't remember ever setting that, or is that a calculated/measured value?

Regards,

Wim

The fast and dirty way to correct the problem is to edit 'client_state.xml' file in the Boinc folder. First make sure that you exit Boinc and that it is completly stopped. Make a back up of the file.
Open the client_state.xml for edit in notepad.
For each project there will be a line

<duration_correction_factor>x.xxxxxx</duration_correction_factor>

change the number to 1.000000

Save file (not 'save as')

Restart Boinc.

---

Boinc V 7.4.36
Win7 i5 3.33G 4GB NVidia 470

Restart Boinc.

Done that, seems to have done the trick!

Thanks for the help.

Regards,

Wim

---