Duration Correction Factor (DCF) Variation

Winterknight
Winterknight
Joined: 4 Jun 05
Posts: 1220
Credit: 312126275
RAC: 663427
Topic 193828

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.

Bikeman (Heinz-Bernd Eggenstein)
Bikeman (Heinz-...
Moderator
Joined: 28 Aug 06
Posts: 3522
Credit: 686046746
RAC: 579703

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

Winterknight
Winterknight
Joined: 4 Jun 05
Posts: 1220
Credit: 312126275
RAC: 663427

RE: The intention was to

Message 84087 in response to message 84086

Quote:

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


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 ;-)

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752761155
RAC: 1451532

RE: Obviously the plan to

Message 84088 in response to message 84086

Quote:
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.


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

archae86
archae86
Joined: 6 Dec 05
Posts: 3145
Credit: 7023494931
RAC: 1808886

RE: I still don't see why

Message 84089 in response to message 84087

Quote:
I still don't see why it was changed.


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.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752761155
RAC: 1451532

RE: I still don't see why

Message 84090 in response to message 84087

Quote:
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 ;-)


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

Winterknight
Winterknight
Joined: 4 Jun 05
Posts: 1220
Credit: 312126275
RAC: 663427

RE: RE: I still don't see

Message 84091 in response to message 84090

Quote:
Quote:
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 ;-)

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


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.

Richard Haselgrove
Richard Haselgrove
Joined: 10 Dec 05
Posts: 2139
Credit: 2752761155
RAC: 1451532

RE: Looking at son's

Message 84092 in response to message 84091

Quote:
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.


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.

Winterknight
Winterknight
Joined: 4 Jun 05
Posts: 1220
Credit: 312126275
RAC: 663427

RE: RE: Looking at son's

Message 84093 in response to message 84092

Quote:
Quote:
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.

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.


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.

Nothing But Idle Time
Nothing But Idl...
Joined: 24 Aug 05
Posts: 158
Credit: 289204
RAC: 0

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(?).

Alinator
Alinator
Joined: 8 May 05
Posts: 927
Credit: 9352143
RAC: 0

RE: I'm probably not adding

Message 84095 in response to message 84094

Quote:
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(?).

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

Comment viewing options

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