estimated vs actual runtimes

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 0
Topic 190557

Over the last week, my estimated runtimes have risen by about half an hour while my actauls have remained the same (6/5.5 for einstien, 4:45/4:15 for albert). The wierd part is that most of the extra time persists until just before completion. I'll have an albert with 4H run, 90% complete, 1H till completion; 15 minutes later it's done and ready to submit. What gives?

Tern
Tern
Joined: 27 Jul 05
Posts: 309
Credit: 99,440,614
RAC: 10

estimated vs actual runtimes

BOINC version? DCF from the hosts page? If you're getting a mix of Einsteins and Alberts, and your host does one a bit "more efficiently" than the other, one result that is "too long" compared to the estimate will raise your DCF and cause what you are seeing for the next 10 results before it can be corrected. If in that 10, another "too long" one comes through, it will all start over. It sounds like you had one or more results in the last batch(es) of 10 that took a half-hour longer than the project estimated based on your benchmarks.

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 0

5.2.13 windows 32. I've had

5.2.13 windows 32. I've had a mix of einsteins and alberts lately, both were affected similarly.

DCF? Not found in the wiki.

MarkF
MarkF
Joined: 12 Apr 05
Posts: 393
Credit: 1,516,715
RAC: 0

Duration Correction Factor on

Duration Correction Factor
on the computer summary page

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 0

Result duration correction

Result duration correction factor 1.085671

Edit: I have noticed to completion times are dropping, so it seems as though the system's slowly adjusting back towards equilibrium.

Tern
Tern
Joined: 27 Jul 05
Posts: 309
Credit: 99,440,614
RAC: 10

RE: Result duration

Message 23812 in response to message 23811

Quote:

Result duration correction factor 1.085671

Edit: I have noticed to completion times are dropping, so it seems as though the system's slowly adjusting back towards equilibrium.

Yep - I'd guess that the "too long" result kicked your DCF up to 1.2 or so, and it's dropping back towards where it should be. My AMD 3700 runs about 1.02, while my Mac Mini runs at 0.42 (normal for Macs thanks to low benchmarks and Altivec-enhanced app). I would guess that your 3800 X2 would normally run a bit below 1.0, maybe around 0.95, as benchmarks for dual-cores are usually a _little_ bit low. (Yours are 2100/4000 while mine are 2400/4400.)

BOINC versions before V4.72 didn't include the DCF at all, 4.72 had it "sortof right", 5.2.x does a much better job on the estimated run times. It's still over-sensitive to a single "way off" result though, and the early Albert WUs had quite a few of those. The "to-completion" time is the project estimate, divided by your benchmarks, then mutliplied by the DCF. The DCF was put in because the benchmarks were so far off on some systems. (For example, the benchmark says my Mac should take over 12 hours/WU instead of just under 6. The DCF "fixes" this, at least fairly well.)

DanNeely
DanNeely
Joined: 4 Sep 05
Posts: 1,364
Credit: 3,562,358,667
RAC: 0

RE: RE: Result duration

Message 23813 in response to message 23812

Quote:
Quote:

Result duration correction factor 1.085671

Edit: I have noticed to completion times are dropping, so it seems as though the system's slowly adjusting back towards equilibrium.

Yep - I'd guess that the "too long" result kicked your DCF up to 1.2 or so, and it's dropping back towards where it should be.

Is this dependent on used CPU time, or just chronological values? In the latter case I can easily see where the displacement came from, but the only work units I see where my claimed and earned credit were significantly off I was underclaiming which should push my DCF down.

Quote:

My AMD 3700 runs about 1.02, while my Mac Mini runs at 0.42 (normal for Macs thanks to low benchmarks and Altivec-enhanced app). I would guess that your 3800 X2 would normally run a bit below 1.0, maybe around 0.95, as benchmarks for dual-cores are usually a _little_ bit low. (Yours are 2100/4000 while mine are 2400/4400.)

Yeah, running the numbers to undo my current 1.07 to get the server estimate, and then using my just finished WU to compute it fresh gets .95.

Quote:

The DCF was put in because the benchmarks were so far off on some systems. (For example, the benchmark says my Mac should take over 12 hours/WU instead of just under 6. The DCF "fixes" this, at least fairly well.)

It seems to me the solution should have been to write an altivec aware benchmark.

Keck_Komputers
Keck_Komputers
Joined: 18 Jan 05
Posts: 376
Credit: 5,744,955
RAC: 0

RE: 5.2.13 windows 32.

Message 23814 in response to message 23809

Quote:

5.2.13 windows 32. I've had a mix of einsteins and alberts lately, both were affected similarly.

DCF? Not found in the wiki.


http://boinc-doc.net/boinc-wiki/index.php?title=Result_Duration_Correction_Factor

http://boinc-doc.net/boinc-wiki/index.php?title=BOINC_Acronyms

BOINC WIKI

BOINCing since 2002/12/8

MarkF
MarkF
Joined: 12 Apr 05
Posts: 393
Credit: 1,516,715
RAC: 0

Dan: DCF is related to the

Dan:
DCF is related to the ratio of your actual cpu time to your expected cpu time (based on the benchmarks). Check the wiki again.

Tern
Tern
Joined: 27 Jul 05
Posts: 309
Credit: 99,440,614
RAC: 10

RE: Is this dependent on

Message 23816 in response to message 23813

Quote:
Is this dependent on used CPU time, or just chronological values? In the latter case I can easily see where the displacement came from, but the only work units I see where my claimed and earned credit were significantly off I was underclaiming which should push my DCF down.

CPU times only, not "wall time".

Quote:
It seems to me the solution should have been to write an altivec aware benchmark.

Optimized BOINC Clients are available, but since only SETI and Einstein have Altivec-optimized applications (SETI is from a 3rd-party), when I started crunching on other projects I backed out the optimized Client.

gravywavy
gravywavy
Joined: 22 Jan 05
Posts: 392
Credit: 68,962
RAC: 0

RE: RE: Is this dependent

Message 23817 in response to message 23816

Quote:
Quote:
Is this dependent on used CPU time, or just chronological values? In the latter case I can easily see where the displacement came from, but the only work units I see where my claimed and earned credit were significantly off I was underclaiming which should push my DCF down.

CPU times only, not "wall time".
...

except on Win-9x & Win-ME, because those operating systems don't have a proper cpu time tracker the client has to be based on on wall time;

AND

remembering that if your machine has been busy on other tasks that in itself pushes the cpu time up due to the time taken by the app to reload its cache every time it gets posession of the cpu again.

So for example running BOINC in the backgroud with a game in foreground will increase the cpu time as well as the wall time for that wu especially if that game goes beyond the abilities of yur graphics card. On an older machine even running the E@h screensaver can do this - leave the s/s on overnight and see how much your estimated runtimes change!

I also see this effect once a week when my virus checker does a full scan of the hard disk - that is intensive enough to blip the DCF enough to notice with the nice steady Einstein apps (though not enough to show on any other project, nor with the Albert app)

R~~/~~g

~~gravywavy

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.