Duration Correction Factor (DCF) Variation
7 Aug 2008 13:21:04 UTC
Topic 193828
(moderation:
Think this needs a separate thread.
Cannot help wondering why there was a need to mess with the completion estimates so that a hosts DCF varies considerably. The consequences of this could cause concern to many users. Especially as we will probably be seeing this for the next couple of months, until all S5R3 units are completed.
I think it was first mentioned by archae86 in Woohoo! I got my first S5R4 task. :-D thread.
At explanation of varying DCF is given in the reply by Gary in post 86566.
Duration Correction Factor (DCF) Variation
)
The intention was to get DCF closer to 1.0 for S5R4 units (S5R3 should very soon try out).
I've seen DCFs of 0.14 and lower at the end of S5R3, resulting in a 7 fold overestimate of runtime for newly attached BOINC users, who might well be scared by the estimate and detach right away if they are unfamiliar with the DCF concept.
Obviously the plan to get DCF to ca. 1.0 didn't work out and the goal was overshot, so some corrections are likely in the near future to get it about right.
CU
Bikeman
RE: The intention was to
)
I still don't see why it was changed. to me I tended to use DCF as a measure of the efficiency of the applications on all projects.
The DCF's for Seti, default app, Einstein, S5R3 default and CPND on my computers were in the same ballpark. Einstein has now completely and utterly b******d that up. This bunny is not a happy bunny ;-)
RE: Obviously the plan to
)
No quarrel with that. Having a target somewhere close to reality, and having an overshoot by mistake and correcting it later, are both reasonable in the circumstances.
But for new users, an overshoot by almost 60% (I reported 1.586961 in the 'performance' thread) is, if anything, worse than an undershoot: in "Manic Credit Hound Emulation" mode (â„¢ Astropulse), it's easy to over-cache and end up with EDF/deadline miss problems.
And remember that DCF values typically start from a higher base on older/slower systems. My Celeron 400 MMX is currently registering 0.7410 from S5R3 work: I'll let you know what it corrects to for S5R4 - in about a fortnight! (projecting about 8 days for the task, 50% share)
Edit - 1.8GHz P4 'Northwood' reported in while I wasn't concentrating. DCF now 1.913994
RE: I still don't see why
)
The initial estimate distributed with the downloaded task is used both to decide how much work to download, and to display a forecast to the user of how long they may expect the task to run.
Having that initial estimate (before task duration correction factor learning kicks in) be close to the truth directly affects the new user experience quite strongly--as it governs initial download sizing, and completion and progress reporting accuracy.
Also, there seem to be abnormal conditions which reset this number to 1.00. Having the correct value be close to 1 reduces the magnitude of the bad transients when this happens.
The tricky bit is weighing these benefits against the problems of the transition--not all of which appear to have been anticipated.
My personal balance of the considerations is that making the attempt was a good idea.
RE: I still don't see why
)
Disagree. Unless you're going to enforce cross-project parity (and where have I heard that phrase before), DCFs will never be comparable. My Xeon has:
1.5312 at Climate Prediction
1.5910 at LHC
3.7855 at Orbit
0.1657 at SETI
About the only one which has got it remotely right is CPDN Beta, at 1.0061
RE: RE: I still don't see
)
Looking at son's account that is doing CPND 0.48, Einstein 0.43 and SetiB 0.35 (not completed AP unit recently). edit] He's trying to clear the CPND units at the moment, so he say's via skype.
RE: Looking at son's
)
You do mean Climate prediction, don't you? I usually call it CPDN. My Q6600s are both around 1.41 - but I've only run CM3 (coupled) models. They have other programs too - if you can find out which one your son is running, I'll ask them to watch out for it. They're beta testing (and quite close to release, I believe) a whole new set of applications with BOINC v6 compatibility.
RE: RE: Looking at son's
)
I'll have to get back to you on that, he was actually just sying good-bye, he's on flexi hrs and was on his way to his home via tesco's, apparent shortage of coffee.
I'm probably not adding
)
I'm probably not adding anything to this discussion, but whatever... my DCF on S5R3 was 0.438 and jumped to 2.055 for S5R4. What can I make of this? Nothing because the DCF is relative to actual runtime versus estimated runtime. All I know for certain is that S5R3 ran for 17.75 hours and S5R4 ran for 24.75 hours or an increase of 39%. I will accept that Bernd is monitoring the situation and will compensate accordingly, though some prodding from the community may be required(?).
RE: I'm probably not adding
)
LOL...
No problemo! The only dumb question is the one you don't ask. ;-)
In the strictest sense, TDCF gives you some insight into two things.
The first and primary one is how close is the floating point operations estimate (f_pop) from the project to what the actual number of operations it takes to run the task is.
Secondarily, it also gives some feel for how closely the benchmarks approximate the real time performance of the CPU.
It's primary use in BOINC is to allow the work scheduling and work fetch functions to get a better estimate of how many tasks your host can take on for a given set of Projects, Resource Share settings, and Work Cache setting.
HTH,
Alinator