To the powers that be:

I'm assuming that the "to completion" column that lists the 'estimated time' to complete a WU is based on each machine's Whetstone and/or Dhrystone estimations, but I invariably find that the figure is either high by about 25% or low by about 15%, depending on the machine I run it on (all under Windoze, for now).

Examples:
2.4 P4/512MB running Win2K - estimate is 6:53, actual is usually around 4:30

133 P2/128MB running Win2K - estimate is 24:52, actual is usually around 16:15

2.4 Cel/256MB running Win2K - estimate is 6:53, actual was 10:30. I upgraded to a gig of memory and it fell to 8:30-8:45.

Is there any way to 'fix' the calculations so they are close to actual? This would balance the requests (at least in my case), so I'm downloading only what I would actually complete and hitting the server less frequently. (I'm sure I'm not the only one that's noticed this :-> )

---

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT

The number is based solely on the number of operations the project states are in the workunit, divided by the Whetstone, and corrected by an appropriate factor to get the units to convert.

There can be three ways this is off (that I can think of):
1) The number of operations the project states are in the WU may be different than the number of operations actually in the WU.
2) Since Whetstone runs alot of trig-heavy calculations, and SETI is low on trig calculations, the Whetstone is now 100% accurate.
3) Since Whetstone does not take into account memory/HDD access and BOINC applications can be very dependant on these, these can slow the system without being able to be estimated by the Whetstone mark. This was seen in your 3rd example.

However, for what it is (a quick way to get in the ballpark of the correct time it'll take to complete a file) I think the number is probably accurate enough. Getting it more accurate may require more overhead, thus reducing processing speed (even minimally), which is counter-productive.

How is the estimated time being off as much as a factor of 50-60% affecting you overly adversely?

---

<img border="0" src="http://www.boincsynergy.com/images/stats/comb-1140.jpg" /><img border="0" src="http://seti.mundayweb.com/stats.php?userID=768" />

> Getting it more accurate may require more overhead, thus reducing processing
> speed (even minimally), which is counter-productive.

It seems to me that EVERY WU I d/l on each box shows the exact same completion time estimate that doesn't change, so I would assume this is a 'one-time' calculation on each file. Changing it wouldn't impact the server or client significantly.

> How is the estimated time being off as much as a factor of 50-60% affecting
> you overly adversely?

I used to have an old 133 deployed that would average 100:30 per WU (as opposed to an estimate of 86:45). Invariably, WUs would occasionally run past deadline on this box and it got me thinking of bandwidth and server load. A more accurate prediction for everyone would tend to work better for everyone, since their boxes wouldn't d/l more than they could crunch, nor would they run out of work (barring network, power, and other 'acts-of-God' issues).

---

Stewie: So, is there any tread left on the tires? Or at this point would it be like throwing a hot dog down a hallway?

Fox Sunday (US) at 9PM ET/PT

One problem with trying to get a better estimate is that it may break the other estimates. This was done at one time when someone 'fixed' the estimate to match what they were seeing on a celeron, everyone else was getting estimates that were about 6 times actual then.

---

BOINC WIKI

BOINCing since 2002/12/8

Esitmate for # of FP ops in every WU is currently a fixed number. It doesn't change (from seti). 27.9x10^12

So, if your WU uses less, the estimate is off...if it takes more...again estimate is off.

Not to mention that the estimate completion time is simply [est_fp_ops] / [host_fp_bench_score] seconds.

---

> > Getting it more accurate may require more overhead, thus reducing
> processing
> > speed (even minimally), which is counter-productive.
>
> It seems to me that EVERY WU I d/l on each box shows the exact same completion
> time estimate that doesn't change, so I would assume this is a 'one-time'
> calculation on each file. Changing it wouldn't impact the server or client
> significantly.
>

I don't think it's a one-time calculation, as that number decreases as you run the WU. The reason it's the same each time is that the calculation is operations / Whetstone * conversion factor. The number of operations is reported to BOINC by SETI to be the same for each WU (regardless of the truth of that statement) and the Whetstone doesn't change unless you re-run your benchmarks, hence the estimate is the same for each WU.

Ostensibly when we start seeing the AstroPulse WUs and other types of WUs SETI would have a different estimate of operations for those WUs and we would see different completion estimates.

---

<img border="0" src="http://www.boincsynergy.com/images/stats/comb-1140.jpg" /><img border="0" src="http://seti.mundayweb.com/stats.php?userID=768" />

> Esitmate for # of FP ops in every WU is currently a fixed number. It doesn't
> change (from seti). 27.9x10^12
>
> So, if your WU uses less, the estimate is off...if it takes more...again
> estimate is off.
>
> Not to mention that the estimate completion time is simply [est_fp_ops] /
> [host_fp_bench_score] seconds.
>
>
>I thought I saw SetiClassic saying that each workunit requires almost 4 x 10^12 flops. Why this big discrepancy of about seven times?

---

>I thought I saw SetiClassic saying that each workunit requires almost 4 x 10^12 flops. Why this big discrepancy of about seven times?

Along with the seti source code is included a "sample test WU". So after you finish compiling seti, you can check if it worked correctly by crunching this WU.
They also include the "result" file you should get if everything worked out ok.

I ran a test using Intel's Vtune monitoring tool on the windows seti executable (setiathome_4.09_windows_intelx86.exe) with this sample WU.

I told Vtune to watch the # of x87 floating point operations that occured.

From the description on Intel's info pages this apparently includes each internal logic FP operation for built in trigonometric functions of the CPU. (example 'fsin' generates about 55 FPOPS)

Apparently the WU contained 5.783 trillion FPOPS.

My time to complete for this sample WU is about 25% greater than my normal time, so I'm going to guess there were 25% more FP ops.

---

> I don't think it's a one-time calculation, as that number decreases as you run
> the WU. The reason it's the same each time is that the calculation is
> operations / Whetstone * conversion factor. The number of operations is
> reported to BOINC by SETI to be the same for each WU (regardless of the truth
> of that statement) and the Whetstone doesn't change unless you re-run your
> benchmarks, hence the estimate is the same for each WU.

Once the work unit starts, the science application has a fair idea of how far it is into the work unit, and it knows how much clock time has elapsed, so it gets more accurate as the work unit progresses.

... but it's still an estimate right up until the WU is finished.

---

> Is there any way to 'fix' the calculations so they are close to actual? This
> would balance the requests (at least in my case), so I'm downloading only what
> I would actually complete and hitting the server less frequently. (I'm sure
> I'm not the only one that's noticed this :-> )

I just set my cache according to the actual crunch time.
Estimated is 4h:30mim, actual around 3H:15min. So setting the cache to 6 days gives me 4 days worth.

---

Grant
Darwin NT

> > How is the estimated time being off as much as a factor of 50-60%
> affecting
> > you overly adversely?
>
> I used to have an old 133 deployed that would average 100:30 per WU (as
> opposed to an estimate of 86:45). Invariably, WUs would occasionally run past
> deadline on this box and it got me thinking of bandwidth and server load. A
> more accurate prediction for everyone would tend to work better for everyone,
> since their boxes wouldn't d/l more than they could crunch, nor would they run
> out of work (barring network, power, and other 'acts-of-God' issues).

Had the same problem with some of my old laptops. SOLUTION: Set up two sets of general prefs. One for fast machines (lets say general defaults) and one for slow machines (let's call it "work"). Set number of days between connects to, let's say, 2 for general (fast) and .5 for work (slow). Works like a champ.

---

- da shu @ HeliOS,
"A child's exposure to technology should never be predicated on an ability to afford it."

> Once the work unit starts, the science application has a fair idea of how far
> it is into the work unit, and it knows how much clock time has elapsed, so it
> gets more accurate as the work unit progresses.
>
> ... but it's still an estimate right up until the WU is finished.

Oh SO true. Did you ever see those predictor w/units that would go to 103% with 0 time remaining and then drop to 97% with a good remaining estimate? Loved those. LOL

> >I thought I saw SetiClassic saying that each workunit requires almost 4 x
> 10^12 flops. Why this big discrepancy of about seven times?
>
> Along with the seti source code is included a "sample test WU". So after you
> finish compiling seti, you can check if it worked correctly by crunching this
> WU.
> They also include the "result" file you should get if everything worked
> out ok.
>
> I ran a test using Intel's Vtune monitoring tool on the windows seti
> executable (setiathome_4.09_windows_intelx86.exe) with this sample WU.
>
> I told Vtune to watch the # of x87 floating point operations that occured.
>
> From the description on Intel's info pages this apparently includes each
> internal logic FP operation for built in trigonometric functions of the CPU.
> (example 'fsin' generates about 55 FPOPS)
>
> Apparently the WU contained 5.783 trillion FPOPS.
>
> My time to complete for this sample WU is about 25% greater than my normal
> time, so I'm going to guess there were 25% more FP ops.
>
>
Thanks, Benher. Maybe the Vtune counter added to the number of flops while doing its counting, and also to the calculation time. If it has to count each and every flop, that's a lot of extra work I would think.

---

> Thanks, Benher. Maybe the Vtune counter added to the number of flops while
> doing its counting, and also to the calculation time. If it has to count each
> and every flop, that's a lot of extra work I would think.

Nope, not really. Every CPU since Pentium II I believe P3 for sure, has had internal CPU counters that are allways ticking away. You just need an outside program to setup a watch for the counters, note the starting number (before your app starts) and ending number. They have 40 bits of resolution, allowing a number up to 2^40 before wrapping back to 0.

> > Thanks, Benher. Maybe the Vtune counter added to the number of flops
> while
> > doing its counting, and also to the calculation time. If it has to count
> each
> > and every flop, that's a lot of extra work I would think.
>
> Nope, not really. Every CPU since Pentium II I believe P3 for sure, has had
> internal CPU counters that are allways ticking away. You just need an outside
> program to setup a watch for the counters, note the starting number (before
> your app starts) and ending number. They have 40 bits of resolution, allowing
> a number up to 2^40 before wrapping back to 0.
>
That, and the number returned by Vtune is too LOW if you believe that a WU consists of 28 TFLOPs. Also, regardless of anything else, a BOINC WU dosen't take anywhere near 7x as long as a classic WU as the FLOP count would indicate. I'd say the Vtune numbers are fairly accurate, and that the BOINC numbers are off (perhaps 28 TFLOPs is a worst case WU?).

Puffy

---

> That, and the number returned by Vtune is too LOW if you believe that a WU
> consists of 28 TFLOPs. Also, regardless of anything else, a BOINC WU dosen't
> take anywhere near 7x as long as a classic WU as the FLOP count would
> indicate. I'd say the Vtune numbers are fairly accurate, and that the BOINC
> numbers are off (perhaps 28 TFLOPs is a worst case WU?).
>
> Puffy

No, both David Anderson and Eric Korpela (the authors of Boinc and Seti.exe respectively) agree with the 5.7 number.

27.9 number was solely an attempt to get the estimated completion times more accurate...back before bugs were discovered in the benchmarks themselves...whos correction caused the bench numbers to be smaller for everyone.

Here is the link for Boinc's explanation of this area.