Every time I crunch WUs with high AR, my DCF increases to around 0.6xxxxx, it then puts estimated time to completion out to more than double the true time for normal WUs

I can then wait for the DCF to gradually work its way back to 0.3xxxxx OR I can edit the DCF in order to get my cache up to more than 1 WU.

I think the splitter estimates are also part of the reason for the excessively long deadlines.

As I recently posted in another thread, my old P233 MMX made it's Christmas Day deadline with 47 days to spare.

My Athlon XP 2200+ crunches short WUs in around 2hr 20mins. AR 0.40xxxx are usually done in about 6hr30, while a lower AR 0.3xxxxx WU may take closer to 7 hrs.

I've just checked my BoincView logs and of the last 350 results only 21 took longer than 6hr30 and 8 of those were completed inside 6hr45. The highest crunch time was ~7hr39 with another 7 in excess of 7 hours.

I am using an optimized app, but I think the splitter estimate times need checking as this seems to be a major part of the deadline problem.

[edit]
Missed a few words off.

---

Sir Arthur C Clarke 1917-2008

Yes, I agree - there are some weird anomalies in the FLOP estimating/counting for the SETI apps that I don't fully understand yet.

We need someone like Joe Segur to confirm this, but I think that the only estimation the splitters make is the number of FLOPs anticipated at a particular AR. From the estimated FLOP count, you can derive both the deadline (number of days from issue - same for everyone) and the crunch time (depends on DCF and benchmarks - specific to your computer in its current state). I hope that someone will be able to donate some free time to Eric, so that he has a chance to work out the true relationship between AR and FLOPs and flatten the curve.

I was thinking about this this morning, when I saw the figures for result 655809526

Sent 10 Nov 2007 10:45:58 UTC
Report deadline 22 Dec 2007 9:40:27 UTC
Computer ID 3751792
CPU time 5964.3125
WU True angle range: 0.129365

Spikes Pulses Triplets Gaussians Flops
0 6 0 0 28222578359970

Claimed credit 93.1117424810837

So that's a (comparatively) short deadline and a quicker than average crunch, even for my stock Q6600 with Crunch3r SSE3. Yet it must have counted an awful lot of FLOPs to claim 93 cobblestones.

OK, I reported and got credit for my first 2008 WU, a nice 87.77 credits. http://setiathome.berkeley.edu/result.php?resultid=655940433

Task ID 655940433
Name 15fe07ad.16851.21340.4.6.23_0
Workunit 177926293
Created 10 Nov 2007 12:22:27 UTC
Sent 10 Nov 2007 14:03:10 UTC
Received 12 Nov 2007 1:44:42 UTC
Server state Over
Outcome Success
Client state Done
Exit status 0 (0x0)
Computer ID 3001110
Report deadline 23 Jan 2008 21:50:38 UTC
CPU time 26243.75
stderr out <core_client_version>5.10.7</core_client_version>
<![CDATA[
<stderr_txt>


Optimized SETI@Home Enhanced application
Optimizers: Ben Herndon, Josef Segur, Alex Kan, Simon Zadra
Version: Windows SSE 32-bit based on S@H V5.15 'Noo? No - Ni!'
Revision: R-2.4V|xK|FFT:FFTW3_SSE|Ben-Joe
CPUID: AMD Athlon(tm) XP 2200+
Speed: 1 x 1799 MHz
Cache: L1=64K L2=256K
Features: MMX SSE

Work Unit Info
WU Credit multi. is: 2.85
WU True angle range: 0.309095
Restarted at 8.48 percent.
Restarted at 13.59 percent.
Restarted at 21.25 percent.
Restarted at 31.60 percent.
Restarted at 63.95 percent.
Restarted at 79.56 percent.

Spikes Pulses Triplets Gaussians Flops
2 4 0 2 26603643893931

</stderr_txt>
]]>
Validate state Valid
Claimed credit 87.7715074506228
Granted credit 87.771390389708
application version 5.28

I thought that one was going to go over 7 hours, and it did. 26243.75 seconds = 7:17:23

When I got that WU, I had recently crunched several short ~ 2:20 WUs so my DCF had gone out to ~ 0.6xxxxx. The original estimated crunch time was over 19 hours. I edited the DCF by changing the first decimal digit from a 6 to a 3 which brought the estimated crunch time closer to reality.

It seems strange that I need to do this since the release of multibeam, I don't remember needing to do it before that, but I could be wrong on this.

Maybe I notice this more than the power crunchers who get through well over 20 WUs per day. I rarely get through more than 8, less than 4 per day if they are AR = 0.4xxxxx

Keith, the dcf goes down slowly, but will instantly increase if one wu exceeds the predicted time. This is done to prevent overloading of work (atleast attempt to) due to unrealistically low values. It takes about 24 wus for the dcf to correct itself downward. This depends on project, wu consistancy, etc. It's behaved this way since Boinc 4.35 or 4.45 (my memory is fading). The concern is too much work on hand and missed deadlines, so it failsafes to highest value.

That's the odd thing. Your 87.77 credits were given an initial 'deadline allocation' of 74.32 days. My 93.11 credits had a 'deadline allocation' of 41.95 days. Something very non-linear there: I'll go and have a look at my graphs and try and work out what it is.

Keith, the dcf goes down slowly, but will instantly increase if one wu exceeds the predicted time. This is done to prevent overloading of work (atleast attempt to) due to unrealistically low values. It takes about 24 wus for the dcf to correct itself downward. This depends on project, wu consistancy, etc. It's behaved this way since Boinc 4.35 or 4.45 (my memory is fading). The concern is too much work on hand and missed deadlines, so it failsafes to highest value.

Thanks, I had a general idea how it worked.

I try to be very careful if I ever need to edit DCF or any other client_state setting. I once got it wrong and downloaded about 3 times more short WUs than I needed.

MB so far seems to have 2 or 3 main AR groups. 0.40xxxx seems to be the most common recently. As a Beta tester I have read and participated in the SETI Beta forums, so I know this is very much a "work in progress", I am trying to add some constructive suggestions and observations to try to improve SETI.

I only edit DCF rarely, I am trying to maintain an RAC above 100 for SETI, while running 5 other projects as well. I've managed this for over 45 days so far according to BOINCstats. I've found that one of the best ways for me to increase RAC is to have a few days cache in reserve.

---

Sir Arthur C Clarke 1917-2008