estimated vs actual runtimes
8 Jan 2006 19:34:44 UTC
Topic 190557
(moderation:
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?
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.
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.
Duration Correction Factor on
)
Duration Correction Factor
on the computer summary page
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.
RE: Result duration
)
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.)
RE: RE: Result duration
)
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.
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.
It seems to me the solution should have been to write an altivec aware benchmark.
RE: 5.2.13 windows 32.
)
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
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.
RE: Is this dependent on
)
CPU times only, not "wall time".
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.
RE: RE: Is this dependent
)
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