The hosts listed are AFAICT not running an optimized version of setiathome_enhanced

At least host 3726 |694.8 |755.6 |(Windows AMD) is running it, $Build: Windows SSE3 Intel Pentium4 and Athlon64 V5.0 by Crunch3r $.

Peter

Joe

Nicely done... Please insure you do not list any of "pappa's" hosts... and Sir Ulli is also close to the top... They are running a Optimized Beta App... TMR is running a non standard app...

Edited for known host ID's
Pappa Host ID's 3427, 3728, 2924, 3730, 3405, 4185
Sir Ulli Host ID 3510
TMR Host ID's 4405, 4404, 3426, 3411

Regards

Al

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project

The hosts listed are AFAICT not running an optimized version of setiathome_enhanced

At least host 3726 |694.8 |755.6 |(Windows AMD) is running it, $Build: Windows SSE3 Intel Pentium4 and Athlon64 V5.0 by Crunch3r $.

Peter

Thanks! I knew about TMR, Crunch3r, and Pappa before starting. I found Sir Ulli by looking at the result, but I was too tired to go back and check all others.

                                                            Joe

Joe

email me off forum and I will be happy to give you the list of Host ID's that I have... al.setiboinc (at) gmail.com There are more...

The hosts listed are AFAICT not running an optimized version of setiathome_enhanced

At least host 3726 |694.8 |755.6 |(Windows AMD) is running it, $Build: Windows SSE3 Intel Pentium4 and Athlon64 V5.0 by Crunch3r $.

Peter

Thanks! I knew about TMR, Crunch3r, and Pappa before starting. I found Sir Ulli by looking at the result, but I was too tired to go back and check all others.

                                                            Joe

Al

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project

Some additional information on the distribution of Test Project systems from the January 29 host.xml file:

Total hosts = 1925
Windows Intel = 1014
Windows AMD = 684
Linux Intel = 71
Linux AMD = 83
All other = 73

                                                        Joe

Well, I think I have time to get back into this thread. The problem with the work calibration is really a problem with using the BOINC benchmarks to calibrate the work done. Whetstone and drhystone aren't really applicable to any real problem.

The real problem is that even in reasonably written code, a modern CPU can spend 90% of its time waiting for memory. CPU speeds have climbed at a much higher rate than the memory speeds have. Because of that, the problem keeps increasing with time.

The following plot displays the amount of credit that would be claimed based upon CPU time versus the amount of time granted for all the valid results from clients of version 5.0 and higher. The red line is where granted equals claimed. So if a point is above the line, that means a CPU got more credit than it would have if the credit was based upon CPU time.



Note that most of the points lie above the line.

The next plot shows the ratio of claimed credit to granted credit vs the benchmark speed of the computer. Values below 1 mean the computer got more credit than it would have from CPU time. The red line is the median value of about 0.4. That means half of the hosts got more than twice the credit they would have from CPU time statistic. You'll see there's a trend to this data. In general, faster CPUs report more (CPU time based) work than slow CPUs. The green line is the best fit straight line to this data.



The final plot shows the ratio of the FLOPs based upon CPU time*benchmark divided by the actual number of FLOPs in a work unit. If we assume that these CPUs do 1 FLOP per cycle when running the benchmark, we can consider this to be the number of actual FLOPS per clock. Again, faster CPUs do less work per clock cycle than slower CPUs. The red line is the median of about 4 cycles per flop. The green line is the best fit line. The yellow lines are what you would expect if processing speed was only dependent on memory bandwidth. The top line is 533 MB/s. The next line is 1067 MB/s. The third is 2133 MB/s. These numbers are read/write bandwidth, whereas benchmarks are typically read-only bandwidth.

---

@Eric
Thanks for the info, that confirms what I had guessed, and why on Seti with a cpu running at 1.86 GHz I only claim ~6 credits, its because my Memory Bandwidth is v.high at 6582 MByte/s.

Andy

Well, I think I have time to get back into this thread. The problem with the work calibration is really a problem with using the BOINC benchmarks to calibrate the work done. Whetstone and drhystone aren't really applicable to any real problem.

Of course not, but BOINC legitimately wanted to arrange things so that hosts would get nearly the same credit per time no matter which project the host was working. Defining "Cobblestones" in terms of benchmarks for a notional machine was not unreasonable, simply not adequate.

The real problem is that even in reasonably written code, a modern CPU can spend 90% of its time waiting for memory. CPU speeds have climbed at a much higher rate than the memory speeds have. Because of that, the problem keeps increasing with time.

The following plot displays the amount of credit that would be claimed based upon CPU time versus the amount of time granted for all the valid results from clients of version 5.0 and higher. The red line is where granted equals claimed. So if a point is above the line, that means a CPU got more credit than it would have if the credit was based upon CPU time.



Note that most of the points lie above the line.

Note that the line includes a lot of length for work which represents a minimal amount of the time which will be used. The big splashes at 40 to 50 granted credits represent the 2.x to 3.x WUs which in the normal distribution of work are rare plus process so much faster that they become a nearly negligible portion of total crunch time. Nobody will dispute that enhanced is granting too much credit for those; if it is not fixed there will certainly be credit hounds aborting all work below 2.0 AR in order to "earn" the higher credit per time.

The line in the vicinity of 191 granted credits is the important part. That's the only normal work done with the 5.0x application. I'd really like to see an expanded plot for only the range above 150 granted credit, 20 or so benchmarks*time calculated credit. Within that range, any result with "Crunch3r" or "TMR" in the stderr.txt should be eliminated or plotted in a different color; discussing credits granted for the standard application with a plot including optimized applications is futile. Similarly, plotting Linux host results in a different color than Windows results would clarify that distinction.

Enough sniping. If the credit system remains as it is the other projects will appreciate the increased interest and enough hosts will remain to get the S@H work done, I just hate to see the promise of cumulative based credits fall apart so soon.

                                                         Joe

Well, the whole question is what is "fair" for the majority of users. Giving credit based upon CPU time rewards machines with slow memory (relative to CPU speed) or small caches and penalizes machines with fast memory. It also provides misrepresentation of the true capacity of BOINC as a whole. For example boincstats.com says the cumulative BOINC stats are 343 TFLOP when the true number is closer to 34 TFLOP.

The people most concerned are the people with the fastest processors, because that's where the disparity between CPU and memory speed is the largest. Right now, 83% of the hosts are getting more credit from the current calibration than they would from CPU time.

I'm going to see if I can find a way to add memory bandwidth into the BOINC credit system, but that will be a slow process.

I'll try to make the plots Joe suggested early next week.

Eric

---

Eric

If you have a reference workunit(s) and want specific tests, I would be happy to take my various machines offline and let them run the reference... I can even add a few more to the mix... Yes, I can then run the same reference workunit with the Optimized Enhanced App to give the added information to the benchmark. That data would then be yours to publish or use as you saw fit... I am here to test, and can test many things...

If you like, you could even send and NDA I read and then go from there...

Well, the whole question is what is "fair" for the majority of users. Giving credit based upon CPU time rewards machines with slow memory (relative to CPU speed) or small caches and penalizes machines with fast memory. It also provides misrepresentation of the true capacity of BOINC as a whole. For example boincstats.com says the cumulative BOINC stats are 343 TFLOP when the true number is closer to 34 TFLOP.

The people most concerned are the people with the fastest processors, because that's where the disparity between CPU and memory speed is the largest. Right now, 83% of the hosts are getting more credit from the current calibration than they would from CPU time.

I'm going to see if I can find a way to add memory bandwidth into the BOINC credit system, but that will be a slow process.

I'll try to make the plots Joe suggested early next week.

Eric

Edit
No I do not have a P133 anymore.. I can drag up a P200 though...
/edit

Al

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project

Well, the whole question is what is "fair" for the majority of users. Giving credit based upon CPU time rewards machines with slow memory (relative to CPU speed) or small caches and penalizes machines with fast memory. It also provides misrepresentation of the true capacity of BOINC as a whole. For example boincstats.com says the cumulative BOINC stats are 343 TFLOP when the true number is closer to 34 TFLOP.

The people most concerned are the people with the fastest processors, because that's where the disparity between CPU and memory speed is the largest. Right now, 83% of the hosts are getting more credit from the current calibration than they would from CPU time.

I'm going to see if I can find a way to add memory bandwidth into the BOINC credit system, but that will be a slow process.

I'll try to make the plots Joe suggested early next week.

Eric

Thought about this for a few hours now, and think you should do what is fair for the fastest computers now, because in a few months they are going to become the norm, and in a year if you try to be fair to the slower computers the unfairness is just going to get worse.

From a personal perspective, I know that this computer, could do 12 Seti units/day using standard app, or three Einstein (Einstein) units a day, each of those secnario's would generate ~250 credits/day. (Einstein presently suspended, so no alberts)

An A_R = 0.189 unit took 38+ hrs, the more common 0.4 units take 28h:30m, A_R 3.628 1h:45m, A_R 4.719 2h:16m.
On the fpops credit system in use now that gives the larger A_R units about twice expected on Seti and Einstein, for the most common A_R about 60% and for the low A_R just over 55%.

I'm just a liitle worried that people will either see their RAC decrease because of low credits for common and low A_R, and therefore migrate in droves, and the seriously competitive watch for higher A_R units, and crunch them for the high rewards and abort any other units, which would cause delays and possible database bloat, which has been known to cause serious problems for Matt, et al.

Andy

Just finished my for 5.05 unit. it was an 0.189 AR

WU 698644

119,387.44s 220.14cc

giving me 6.64 cc/hr.

comparible to my cc/hour on 5.02

---

Rogue the Bronze Fireliazed
uninstall dyslexica.o : Permission denied

Athlon 64 3000 w/Windows
Athlon 1800 w/Linux

Bump

Yes we are interested in the update to the graphs.

Joe with me watching various odd AR WU's and credit claimed it looks like Eric's increased iterations are causing a change with claimed credits... That is only an observation... I have not collected numbers.

Well, the whole question is what is "fair" for the majority of users. Giving credit based upon CPU time rewards machines with slow memory (relative to CPU speed) or small caches and penalizes machines with fast memory. It also provides misrepresentation of the true capacity of BOINC as a whole. For example boincstats.com says the cumulative BOINC stats are 343 TFLOP when the true number is closer to 34 TFLOP.

The people most concerned are the people with the fastest processors, because that's where the disparity between CPU and memory speed is the largest. Right now, 83% of the hosts are getting more credit from the current calibration than they would from CPU time.

I'm going to see if I can find a way to add memory bandwidth into the BOINC credit system, but that will be a slow process.

I'll try to make the plots Joe suggested early next week.

Eric

Al

---

Thanks to Paul and Friends
Please consider a Donation to the Seti Project

Another data point: I did some calculations from the Einstein@Home host file and came to the conclusion that on average Linux benchmarks would need to be multiplied by 1.514 to equal Windows benchmarks. There's more detail in this BOINC Forum thread.

"Al (Pappa)" wrote:

Joe with me watching various odd AR WU's and credit claimed it looks like Eric's increased iterations are causing a change with claimed credits... That is only an observation... I have not collected numbers.

That's certainly true in the range where the change adds additional operations. I estimate that 0.426 AR units will be about 194 credits rather than the 191 typical with 5.02. However, there's a crossover so at higher ARs there are fewer operations with 5.05 and correspondingly less credit (and crunch time).

I did some standalone testing to characterize VHAR WUs on my system, here's some results:

true_angle_range= 1.1273
NumCfft= 46355
NumGauss= 174032040
NumPulse= 18703450112
NumTriplet= 2448399794176
wu_cpu_time= 66910.267 (18:35:10.267)
flops= 7154183743804
credits= 74.52

true_angle_range= 1.13
NumCfft= 33469
NumGauss= 0
NumPulse= 18686672896
NumTriplet= 2447862923264
wu_cpu_time= 25278.061 (7:01:18.061)
flops= 4967228908419
credits= 51.74

true_angle_range= 1.801
NumCfft=32157
NumGauss= 0
NumPulse= 6477053952
NumTriplet= 1499480457216
wu_cpu_time= 14944.701 (4:09:04.701)
flops= 3761253684528
credits= 39.18

true_angle_range= 6.8
NumCfft=31597
NumGauss= 0
NumPulse= 543162368
NumTriplet= 427349245952
wu_cpu_time= 10561.538 (2:56:10.538)
flops= 3229483615415
credits= 33.64

true_angle_range= 6979.584
NumCfft=31561
NumGauss= 0
NumPulse= 0
NumTriplet= 0
wu_cpu_time= 9964.404 (2:46:04.404)
flops= 3186771361792
credits= 33.20

                                                      Joe

Well, the whole question is what is "fair" for the majority of users. Giving credit based upon CPU time rewards machines with slow memory (relative to CPU speed) or small caches and penalizes machines with fast memory. It also provides misrepresentation of the true capacity of BOINC as a whole. For example boincstats.com says the cumulative BOINC stats are 343 TFLOP when the true number is closer to 34 TFLOP.

The people most concerned are the people with the fastest processors, because that's where the disparity between CPU and memory speed is the largest. Right now, 83% of the hosts are getting more credit from the current calibration than they would from CPU time.

I'm going to see if I can find a way to add memory bandwidth into the BOINC credit system, but that will be a slow process.

I'll try to make the plots Joe suggested early next week.

Recently also Windows Vista should contain Windows Performance Rating tool, which will take various computer subsystems into account, when calculating it's Overall Rating note. But according to the image, it is rather static noting system, not taking memory bandwidth or system bus throughput into account.

[edit]The only throughput Vista is interested in should be the graphics subsystem throughput (measured by WinSAT.exe tool) because of the hungry Aero Glass.

So this indicates too that (IMO) adding the throughput measurements into Boinc Core Client is more than reasonable and should be more than understood by the community.[/edit]

Peter