Does this correction automagically apply itself over time?
With just a few dozen wu's under my boinc belt it still seems that there is a couple hours difference. I did change horses in mid-stream about 10 days ago and began using self optimized/compiled versions of boinc 4.70 and seti 4.18, originally using the 'stock' clients available in in the download area. While the optimized clients did shave at least an hour or so off the processing time, there's still the disparity in the final numbers. Will this eventually even out or at least become closer?

---

The more WUs you complete, the closer it gets to being accurate.

...At least with the BOINC compiled CC. I don't know if your self optimized CC might have done something odd to that part of the code.

The more WUs you complete, the closer it gets to being accurate.

I shall then endeavor to persevere. You know patience is not a prerequisite to run seti. :)

---

Which version of the Boinc core client enables this new feature?

---

Which version of the Boinc core client enables this new feature?

It's in the latest alpha-builds, v4.7x

You'll never get it perfectly accurate. Due to the differences between WU (including the -9 WU's) you can only hope for a certain amount of accuracy.

Jim

The more WUs you complete, the closer it gets to being accurate.

...At least with the BOINC compiled CC. I don't know if your self optimized CC might have done something odd to that part of the code.

---

If the compute time is greater than expected, the correction factor jumps up so that the new expected time matches the actual time.

If the compute time is less than 10% of the expected time, it is assumed that it is some sort of anomally, and the corrected time is reduced by 1% of the difference.

Otherwise, the corrected time is reduced by 10% of the difference.

---

BOINC WIKI

I've been using it on win since 4.49, and now I've got 4.71, but it seems to systematically overestimate completion times for s@h & pp@h. eg my pp@h time is perhaps a shade over 2 hours, but the estimated time for such units seems stuck at about 3.5 hours, which it reached (downwards) pretty quickly, but it hasn't reduced significantly for at least a week. Could this be due to the assymetrical correction strategy?

BTW it's still a lot better than before, especially in that the ETC never goes to around zero at the beginning of a unit anymore, so I don't get extra downloads for e@h, which is great.

PGY

---

I've been using it on win since 4.49, and now I've got 4.71, but it seems to systematically overestimate completion times for s@h & pp@h. eg my pp@h time is perhaps a shade over 2 hours, but the estimated time for such units seems stuck at about 3.5 hours, which it reached (downwards) pretty quickly, but it hasn't reduced significantly for at least a week. Could this be due to the assymetrical correction strategy?

BTW it's still a lot better than before, especially in that the ETC never goes to around zero at the beginning of a unit anymore, so I don't get extra downloads for e@h, which is great.

PGY

Do you have an occasional WU that takes about 3.5 hours? If so, that would keep the estimate this high, and this was done intentionally, as having a little too much time in EDF or a little less work is less bad than missing a deadline because the estimate was wrong the other direction.

---

BOINC WIKI

I haven't noticed such a wu, although I have been watching out for it. I'll keep watching. I see the point of overestimating, though, and it's not a big deal for me.

PGY

edit - I checked my records on the pp@h site, and there's nothing longer than 2.5 hours

---

Hi John,

I've got another piece of data for you. The same machine I was discussing below (600MHz Dell P3 win98) just took unusually long to complete a s@h unit, as a result of which, the new units in my cache now have a considerably longer ETC. This is before they've started. But the long wu's actual compute time was 15:45 (this is slow even for this machine, which would normally take maybe 7:30 with an optimised seti client), whereas the ETC for the new wus is now 18:52 (previously I think it was too high at something like 12 hrs).

So, sure, it went up in one go, but it went too far. You said below the new ETC should equal the length of such a long wu, but this is almost 20% more.

BTW, how do you calculate the ETC while the wu is running? It looks to me like some sort of weighted mean of the applications's own ETC and one calculated from your adjusted total estimate. Is that it?

PGY

---

BTW, how do you calculate the ETC while the wu is running? It looks to me like some sort of weighted mean of the applications's own ETC and one calculated from your adjusted total estimate. Is that it?

PGY

Yes, it is.

I will have to take another look at the code that does the calculation of the correction factor.

---

BOINC WIKI

Thanks for your attention, John

I've noticed another case that behaves slightly differently than the ones I've reported below. In this case the estimated time rises even though it isn't exceeded by the actual compute time. It involves pp@h on cc 4.71, and I noticed a unit about to finish with an unusually long compute time, so I took notes. Previously, my actual completion time was a bit more than 2:30 but less than 3:00, and initial estimated time for cached units was 3:47. When the long-running unit finished, its actual time was 3:01, which doesn't exceed the previous estimate, yet the new estimate rose to 4:13.

I hope this helps,

PGY

---

After several weeks of running CC 4.72 there still seems to be a difference between actual and estimated crunch time. It is a much better estimate but still not correct and is not moving towards the correct value as it did for the first few days.

Box		Actual	   Est		HT?

Box1		1:30:00	   2:55:20	Y
Box2		1:55:00	   3:20:55	Y
Box3		2:00:00	   3:36:32	Y
Box4		2:00:00	   4:21:43	N

Hope this helps for future versions.

---

Boinc....Boinc....Boinc....Boinc....