what is the result duration correction factor, and how is it calculated? why does it change?
my result correction factor is about 0.18. i was using an alpha version of BOINC Manager, and my result correction factor was about 0.33. tasks seem to be finishing faster with the lower result correction factor.
... tasks seem to be finishing faster with the lower result correction factor.
You are thinking about it the wrong way. The duration_correction_factor (DCF) cannot influence the actual crunch time. It's the other way around. A reduction in the crunch time (perhaps caused by a more efficient science app for example) will cause a reduction in the DCF value. This is simply so that BOINC can continue to refine its estimate for how long future tasks will take to crunch.
EDIT:
I'll also take this opportunity to comment on another hoary old chestnut. You made the statement that
Quote:
my result correction factor is about 0.18. i was using an alpha version of BOINC Manager, and my result correction factor was about 0.33.
Correct me if I'm wrong but by "alpha version of BOINC Manager" do you actually mean the new BOINC 6.1.x development versions which are now available for testing? I believe that people refer to these as "alpha versions" perhaps before they are actually publicly available. If so, then it's probably quite explainable for your DCF to have changed from 0.33 when you were using the development version to 0.18 now that you are apparently on a different version.
The "hoary old chestnut" is not something you have said but rather an interpretation of what a reduction in DCF actually means. I've seen it posted a few times that a reduction in DCF is a sign that you are using a better and more efficient app. Yes, an improved app is a possible reason for the reduction in DCF but it's not the only reason. In your case you appear to have had an increase in DCF from 0.18 to 0.33 when I presume that you haven't actually changed the science app at all - just the version of BOINC. I notice you are currently on the stock version 5.10.45. So it would be quite incorrect to say that your computer has suddenly become "less efficient" or is necessarily using a less efficient app.
The more logical explanation is that there may be a difference in the way benchmarks are being calculated between the two versions of BOINC. Historically there have been problems with benchmarks and how they are calculated, particularly with multi-processor machines. If one version of BOINC under-calculates a benchmark, BOINC will think your machine is a worse performer than it actually is and will increase the estimated crunch times accordingly. When the actual crunch times come in better than expected, it's really a sign that the benchmarks are wrong. However all BOINC can do is reduce the DCF - it can't fix the dodgy benchmarks.
So, in summary, the change in DCF you are reporting is more likely to be due to a difference in the way benchmarks are calculated rather than any difference in efficiency of your computer or the science app. You therefore shouldn't be too concerned about the change you have seen.
at this time, i'm supposing that a low correction factor is more desirable.
Not at all!
The "desirable" DCF is 1.0 which would mean that the project is doing a perfect job of estimating, in advance, how long its tasks should take to crunch. If the project is doing a lousy job with the estimates, the BOINC client will compensate by varying the DCF well away from 1.0.
With a project like E@H, there are ongoing releases of improved beta test apps which eventually become the stock app. These ongoing improvements will be visible as a progressively decreasing DCF for everybody. This is not a sign that the hardware is any "better" - it's really a sign that the Devs should perhaps rethink their estimate of the time that the stock app should now be taking. On the other hand if two different participants had supposedly identical machines, but one had a lower DCF than the other, that would indicate that one host was tweaked rather better than the other.
On top of all this, if you start introducing different architectures which interact differently with a given science app, this will cause further variations in DCF which reflect the efficiency of that architecture in handling the way the app has been compiled. Then you might start thinking about different compilers ....
In other words, for the average cruncher, the DCF will be what it is and you shouldn't worry about it too much. It's just a fudge factor to correct the project supplied estimate so that it will more closely reflect the actual time that your particular machine is likely to take, based on previous crunching history. It is easily thrown into a spin by sudden hardware or software changes and even by the actual tasks themselves because of the cyclic nature of crunch times.
result duration correction factor
)
http://www.boinc-wiki.info/Result_Duration_Correction_Factor
RE: what is the result
)
my result correction factor is about 0.18. i was using an alpha version of BOINC Manager, and my result correction factor was about 0.33. tasks seem to be finishing faster with the lower result correction factor.
RE: ... tasks seem to be
)
You are thinking about it the wrong way. The duration_correction_factor (DCF) cannot influence the actual crunch time. It's the other way around. A reduction in the crunch time (perhaps caused by a more efficient science app for example) will cause a reduction in the DCF value. This is simply so that BOINC can continue to refine its estimate for how long future tasks will take to crunch.
EDIT:
I'll also take this opportunity to comment on another hoary old chestnut. You made the statement that
Correct me if I'm wrong but by "alpha version of BOINC Manager" do you actually mean the new BOINC 6.1.x development versions which are now available for testing? I believe that people refer to these as "alpha versions" perhaps before they are actually publicly available. If so, then it's probably quite explainable for your DCF to have changed from 0.33 when you were using the development version to 0.18 now that you are apparently on a different version.
The "hoary old chestnut" is not something you have said but rather an interpretation of what a reduction in DCF actually means. I've seen it posted a few times that a reduction in DCF is a sign that you are using a better and more efficient app. Yes, an improved app is a possible reason for the reduction in DCF but it's not the only reason. In your case you appear to have had an increase in DCF from 0.18 to 0.33 when I presume that you haven't actually changed the science app at all - just the version of BOINC. I notice you are currently on the stock version 5.10.45. So it would be quite incorrect to say that your computer has suddenly become "less efficient" or is necessarily using a less efficient app.
The more logical explanation is that there may be a difference in the way benchmarks are being calculated between the two versions of BOINC. Historically there have been problems with benchmarks and how they are calculated, particularly with multi-processor machines. If one version of BOINC under-calculates a benchmark, BOINC will think your machine is a worse performer than it actually is and will increase the estimated crunch times accordingly. When the actual crunch times come in better than expected, it's really a sign that the benchmarks are wrong. However all BOINC can do is reduce the DCF - it can't fix the dodgy benchmarks.
So, in summary, the change in DCF you are reporting is more likely to be due to a difference in the way benchmarks are calculated rather than any difference in efficiency of your computer or the science app. You therefore shouldn't be too concerned about the change you have seen.
Cheers,
Gary.
at this time, i'm supposing
)
at this time, i'm supposing that a low correction factor is more desirable.
RE: at this time, i'm
)
Not at all!
The "desirable" DCF is 1.0 which would mean that the project is doing a perfect job of estimating, in advance, how long its tasks should take to crunch. If the project is doing a lousy job with the estimates, the BOINC client will compensate by varying the DCF well away from 1.0.
With a project like E@H, there are ongoing releases of improved beta test apps which eventually become the stock app. These ongoing improvements will be visible as a progressively decreasing DCF for everybody. This is not a sign that the hardware is any "better" - it's really a sign that the Devs should perhaps rethink their estimate of the time that the stock app should now be taking. On the other hand if two different participants had supposedly identical machines, but one had a lower DCF than the other, that would indicate that one host was tweaked rather better than the other.
On top of all this, if you start introducing different architectures which interact differently with a given science app, this will cause further variations in DCF which reflect the efficiency of that architecture in handling the way the app has been compiled. Then you might start thinking about different compilers ....
In other words, for the average cruncher, the DCF will be what it is and you shouldn't worry about it too much. It's just a fudge factor to correct the project supplied estimate so that it will more closely reflect the actual time that your particular machine is likely to take, based on previous crunching history. It is easily thrown into a spin by sudden hardware or software changes and even by the actual tasks themselves because of the cyclic nature of crunch times.
Cheers,
Gary.