By stabilised I mean that -

Previously after crunching an AP the estimated completion times would inflate by ~50% ie 15mins to 22mins for a shortie.

Now after crunching an AP the time only changes by about 5-10 seconds.

As the estimated time is calculated from the TDCF then this means there has basically been negligable change in the TDCF due to AP.

Interesting. I just recently upgraded to r103 AP myself. I'll have to observe it further. If what you say is true, then it is more likely that the TDCF is off because of it being a new host as you suggested. Once the TDCF stabilizes, then work fetch should operate more effectively in the future.

My Q6600 also shows that that the improvements done in AP r103, now mean there is little variation in DCF between MB and AP. It would seem the DCF is fairly stable at about 0.11 +/- 0.01.

By stabilised I mean that -

Previously after crunching an AP the estimated completion times would inflate by ~50% ie 15mins to 22mins for a shortie.

Now after crunching an AP the time only changes by about 5-10 seconds.

As the estimated time is calculated from the TDCF then this means there has basically been negligable change in the TDCF due to AP.

Interesting. I just recently upgraded to r103 AP myself. I'll have to observe it further. If what you say is true, then it is more likely that the TDCF is off because of it being a new host as you suggested. Once the TDCF stabilizes, then work fetch should operate more effectively in the future.

My Q6600 also shows that that the improvements done in AP r103, now mean there is little variation in DCF between MB and AP. It would seem the DCF is fairly stable at about 0.11 +/- 0.01.

My E8500 has been doing VLAR work, so DCF is at 0.16, Because of that Boinc reckons AP work is going to take 12½hrs each,
But with r103 AP, it'll take 6½ to 7 hrs, and DCF will dive.

Claggy

It looks like my main PC got hit with the "no new work" download anyway. From what I saw the scheduler sent the message of no work available. so I hit the NNT button. next thing I know its hitting me with more work. Now I do have a my cache set to 7+ days so I'm not all that disturbed by the amount of work. I know I'll finish it on time. I was just surprised when it did send the tasks

1/24/2009 5:56:37 PM|3x+1@home|Scheduler request succeeded: got 0 new tasks
1/25/2009 10:14:19 AM|SETI@home|Sending scheduler request: To fetch work. Requesting 2331594 seconds of work, reporting 0 completed tasks
1/25/2009 10:14:25 AM|SETI@home|Scheduler request succeeded: got 0 new tasks
1/25/2009 10:14:25 AM|SETI@home|Message from server: (Project has no jobs available)
1/25/2009 10:15:49 AM|SETI@home|Finished download of ap_17dc08ad_B0_P1_00128_20090125_10232.wu
1/25/2009 10:15:49 AM|SETI@home|Started download of ap_17dc08ab_B6_P1_00362_20090125_17514.wu
1/25/2009 10:16:13 AM|SETI@home|Finished download of ap_17dc08ad_B1_P0_00089_20090125_10336.wu
1/25/2009 10:16:13 AM|SETI@home|Started download of ap_21dc08ab_B2_P1_00213_20090124_10181.wu
1/25/2009 10:16:38 AM|SETI@home|Finished download of ap_17dc08ab_B6_P1_00362_20090125_17514.wu
1/25/2009 10:16:38 AM|SETI@home|Started download of ap_17dc08ad_B0_P0_00125_20090125_10227.wu
1/25/2009 10:16:46 AM|SETI@home|Finished download of ap_21dc08ab_B2_P1_00213_20090124_10181.wu
1/25/2009 10:16:46 AM|SETI@home|Started download of ap_20oc08af_B2_P0_00382_20081126_24598.wu
1/25/2009 10:16:55 AM|SETI@home|Finished download of ap_17dc08ad_B0_P0_00125_20090125_10227.wu
1/25/2009 10:16:55 AM|SETI@home|Started download of ap_17dc08ab_B6_P1_00364_20090125_17514.wu
1/25/2009 10:17:01 AM|SETI@home|Finished download of ap_20oc08af_B2_P0_00382_20081126_24598.wu
1/25/2009 10:17:29 AM|SETI@home|Finished download of ap_17dc08ab_B6_P1_00364_20090125_17514.wu

---

In a rich man's house there is no place to spit but his face.
Diogenes Of Sinope

My E8500 has been doing VLAR work, so DCF is at 0.16, Because of that Boinc reckons AP work is going to take 12½hrs each,
But with r103 AP, it'll take 6½ to 7 hrs, and DCF will dive.

Claggy

Bear in mind that downward DCF adjustment is gradual. One AP which was estimated at 12.5 hours and actually crunched in 6.5 hours will reduce DCF by less than 5%. It's a low gravity dive.

                                                                Joe

So, to those of use with less than 2 phd's, how do I get it to download more work?

My first couple of lines btw.

25/01/2009 21:14:51||Starting BOINC client version 6.4.5 for windows_intelx86
25/01/2009 21:14:51||log flags: task, file_xfer, sched_ops
25/01/2009 21:14:51||Libraries: libcurl/7.19.0 OpenSSL/0.9.8i zlib/1.2.3
25/01/2009 21:14:51||Data directory: E:\Utilities\Web\Bionic\xxdata
25/01/2009 21:14:51||Running under account Jonathan
25/01/2009 21:14:51||Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz [x86 Family 6 Model 15 Stepping 2]
25/01/2009 21:14:51||Processor features: fpu tsc pae nx sse sse2 mmx
25/01/2009 21:14:51||OS: Microsoft Windows XP: Home x86 Editon, Service Pack 3, (05.01.2600.00)
25/01/2009 21:14:51||Memory: 1.99 GB physical, 3.84 GB virtual
25/01/2009 21:14:51||Disk: 72.72 GB total, 52.81 GB free
25/01/2009 21:14:51||Local time is UTC +0 hours
25/01/2009 21:14:51||Not using a proxy
25/01/2009 21:14:51||CUDA devices found
25/01/2009 21:14:51||Coprocessor: GeForce 9600 GT (1)
25/01/2009 21:14:51|rosetta@home|URL: http://boinc.bakerlab.org/rosetta/; Computer ID: 983631; location: (none); project prefs: default
25/01/2009 21:14:51|Einstein@Home|URL: http://einstein.phys.uwm.edu/; Computer ID: 1804331; location: (none); project prefs: default
25/01/2009 21:14:51|SETI@home|URL: http://setiathome.berkeley.edu/; Computer ID: 4712958; location: home; project prefs: default
25/01/2009 21:14:51||General prefs: from http://bam.boincstats.com/ (last modified 12-Jan-2009 19:54:03)

---

Ok, I think i got it. The cache size calculation varies and it only give you a ball-park figure. That was why my client requested 0 seconds of work even though 2 cores sat idle.

"OzzFan" wrote:

The problem is that both of you are running on 10 day caches with a project that has 7 day deadlines.
...
No. The reason why you've been idling isn't because of too small a cache, its because comms with the servers have been bogged down.

Yes I tried 10 days, since my 2 day setting ran out of work. But I don't want a 10 day cache, so whenever all my cores get busy I'll change it back to 2 days.

I think the problem I had was that it requested 0 seconds, otherwise the connection would have failed, or the server would have answered with "no work available". I could be wrong here since i have no clue how the serverside behave.

"Claggy" wrote:

Your messages still say: 25-Jan-2009 00:45:52 [---] Reading preferences override file

Yes, I found out that it was easier/faster to change the settings in the gui. I'll try the web-conf when my 2 day cache is back.

Thank you all for your answers and information. My cache is slowly building up to it's previous size. I can only hope this wont happen again... :-)

---

nm, got it, I changed settings from 3 days to 10 and got a little more work.

---

Older versions of BOINC have sever restrictions on work fetch if there is work that is in danger of being late. Please note that if the work is not completed before Connect Ever X before the report deadline, there is no way that BOINC can hope to have the report done before the deadline. Therefore if might complete after that, it is considered in danger of being late. This was removed in the most recent couple of versions at the risk of reporting work late. Full caches of both connect every X and extra work is too much, and work will be reported late.

---

BOINC WIKI

Older versions of BOINC have sever restrictions on work fetch if there is work that is in danger of being late. Please note that if the work is not completed before Connect Ever X before the report deadline, there is no way that BOINC can hope to have the report done before the deadline. Therefore if might complete after that, it is considered in danger of being late. This was removed in the most recent couple of versions at the risk of reporting work late. Full caches of both connect every X and extra work is too much, and work will be reported late.

Seems like another one of those cases where the original good design has been corrupted because of pressure from parties that were too lazy to find out
how the schedulers works, in regard to their own practices. And not realising the effect on other projects.

Older versions of BOINC have sever restrictions on work fetch if there is work that is in danger of being late. Please note that if the work is not completed before Connect Ever X before the report deadline, there is no way that BOINC can hope to have the report done before the deadline. Therefore if might complete after that, it is considered in danger of being late. This was removed in the most recent couple of versions at the risk of reporting work late. Full caches of both connect every X and extra work is too much, and work will be reported late.

Seems like another one of those cases where the original good design has been corrupted because of pressure from parties that were too lazy to find out
how the schedulers works, in regard to their own practices. And not realising the effect on other projects.

Agreed.

---