3.0 GHz Xeon 11,648 Seconds Claimed Credit=12.78
1.8 GHz G5-Single Proc. 11,756 Seconds Claimed Credit=23.87

Now, That's what I call a PENALTY!!!!!

Work Unit: 02fe05aa.20326.11378.86072.25
Here: http://setiweb.ssl.berkeley.edu/workunit.php?wuid=16029260

---

LarryB56

One of the reasons is different boinc cc versions.

---

They are optimised clients....boinc and seti?
What are the benchmarks for each system? You may have to install an optimised boinc client to get the benchmarks up perhaps? Looking at your bench marks they are low. Re-run them with nothing else going on in the system. Try an optimised clinet for boinc and then re-run. I get ~5% extra just through turning off virus scanner during benchnark.

---

The science gets done accurately since they can compare results on different systems. That's a penalty? 8)

---

-----

xeons are lousy at seti. my 2.8's get spanked by my Pentium-M 1400

3.0 GHz Xeon 11,648 Seconds Claimed Credit=12.78
1.8 GHz G5-Single Proc. 11,756 Seconds Claimed Credit=23.87

Now, That's what I call a PENALTY!!!!!

Not really.
The Xeon is crunching 4 WU's at the same time, thus that host is getting
4X12.78=51.12 credits for a certain time frame, the G5-Single Proc. get only 23.87 credits for roughly the same time frame.

3.0 GHz Xeon 11,648 Seconds Claimed Credit=12.78
1.8 GHz G5-Single Proc. 11,756 Seconds Claimed Credit=23.87

Now, That's what I call a PENALTY!!!!!

Not really.
The Xeon is crunching 4 WU's at the same time, thus that host is getting
4X12.78=51.12 credits for a certain time frame, the G5-Single Proc. get only 23.87 credits for roughly the same time frame.

doesn't matter, the xeons should still be either going faster or claiming more credit. by your argument, the xeon should be claiming around 4 x 23.87 = 95.48 credits in the same time frame as a single CPU. at just over half that now, it is falling well short of its potential. with optimized clients, my slower 2.8 xeons take only 6-8k seconds per unit and claim 12-14 credits.

doesn't matter, the xeons should still be either going faster or claiming more credit. by your argument, the xeon should be claiming around 4 x 23.87 = 95.48 credits in the same time frame as a single CPU. at just over half that now, it is falling well short of its potential. with optimized clients, my slower 2.8 xeons take only 6-8k seconds per unit and claim 12-14 credits.

It is not that easy to compare your Xeon with the 3.0GHz one.

Your Xeon has 1GB RAM, the other 4. Your is a 2 CPU, the other a 4 CPU host.

Your host is running Microsoft Windows XP Professional Edition, Service Pack 2, (05.01.2600.00), the other is running Linux 2.4.21-27.0.4.ELsmp.

Your has a Measured floating point speed of 1510.74 million ops/sec and a Measured integer speed of 1385.37 million ops/sec, the other has a Measured floating point speed of 634.94 million ops/sec and a Measured integer speed of 1262.3 million ops/sec.

As a result, you host has a lower CPU time but finally both are nearly equal in claimed credit.

Your has a Measured floating point speed of 1510.74 million ops/sec and a Measured integer speed of 1385.37 million ops/sec, the other has a Measured floating point speed of 634.94 million ops/sec and a Measured integer speed of 1262.3 million ops/sec.

and thats what i think indicates a problem. OS and RAM should not make that significant a difference in CPU benchmarks, especially on a faster CPU. maybe the BOINC client has something to do with it, but its a major performance drop if so.

if the benchmarks are higher, his WU time would claim a more normal credit number

With the default linux Boinc, the bench marks are only about 1/2 the bench marks for windows. On my linux boinc boxes, after I upgraded to one of the optmised boinc cc my bench marks and requested credits doubled. So far in the Boinc world, linux is getting the short end of the stick.

---

With the default linux Boinc, the bench marks are only about 1/2 the bench marks for windows. On my linux boinc boxes, after I upgraded to one of the optmised boinc cc my bench marks and requested credits doubled. So far in the Boinc world, linux is getting the short end of the stick.

Agreed. Did the same and now my fc3 box is just slower than windows on average.

---

The science gets done accurately since they can compare results on different systems. That's a penalty? 8)

xeon's are lousy at just about anything.

---

<a href="http://tinyurl.com/9hemz"><img src="http://www.boincsynergy.com/images/stats/comb-1441.jpg"></img></a>

[font="fixedsys,courier"]Maybe I haven't been in Numbers as often as I should have, but could you explain what you meant by "penalty"?[/font]

---

To determine the credit that should be granted SETI uses the first three returned units [The Quorum] to determine the credit value to be granted.
(I am unsure if more than 3 units are sent out in total)

SETI discards both the upper and lower Values of this Quorum so the value in between is used as the Granted credit value.

so if the first three units have credit values of (from lowest to highest)

15.6 22.4 26.1 SETI will use the value of 22.4

now if you return a unit and you wish to get 34.2 Credit for it SETI will only grant you the 22.4 it determined from the Quorum. (a loss of 11.8)

While you gain on some you lose on others and some think such a large loss of potential credit a bit of a Penalty

---

[font="fixedsys,courier"]Ah. To me "penalty" implies "infraction", like a red card at a soccer match.

I think a better term would be "screwed by the system", but that'll be sure to tick off the Devs.

Thanks for the clarification![/font]

---

Yeah. The THEORY is that different work units (WU's) require different amounts of computing effort, so the points awarded should reflect that. But within the SAME single WU, the amount of computation required is exactly the same regardless of machine type or speed. So the points claimed and awarded for doing a single particular WU should be exactly the same, regardless of how fast or slow a particular machine is, since the total amount of computation, and hence the total contribution to the project and to the science, will be exactly equal for that particular WU.

But the reality is very different, and the awards are very far from the same. The system does NOT work as advertised, and therefore some machines are really getting "screwed" or "penalized", as you said. The Devs must surely be aware of this, so I wouldn't worry about ticking them off. It's the participants like us who should be ticked off, since this has been going on for so long without a fix, while the Devs have been concentrating on fixing other stuff like bugs that crash people's systems, or getting BOINC to the point that Classic SETI can be shut down, etc., etc... ;-)

You might enjoy this related thread, which provides a partial way to compensate:

Here's how to Get More Credit

Enjoy!

---

--Bill

[font="fixedsys,courier"]Ah. To me "penalty" implies "infraction", like a red card at a soccer match.

I think a better term would be "screwed by the system", but that'll be sure to tick off the Devs.

Thanks for the clarification![/font]

If everyone gets the same credit for the same work unit, how is that getting "screwed"?

Equal pay for equal work seems imminently fair.

---

If everyone gets the same credit for the same work unit, how is that getting "screwed"?

Equal pay for equal work seems imminently fair.

It is fair as far as I'm concerned.

This credit system is more equatable system for comparing our overall contrabution by measuring measuring our contrabution against a common reference system as opposed to a work count completed

I'm not sure how some long term contributers felt to see later entents with faster hosts overtake them on ranks they had spent years climbing in months or weeks even

It is fairer then adding all the seconds of all the hosts cycles that went towards SETIs Application (as in Classic) as the hosts will get faster and it will skew over time ranking on the older system.

---

[font="fixedsys,courier"]Ah. To me "penalty" implies "infraction", like a red card at a soccer match.

I think a better term would be "screwed by the system", but that'll be sure to tick off the Devs.

Thanks for the clarification![/font]

If everyone gets the same credit for the same work unit, how is that getting "screwed"?

Equal pay for equal work seems imminently fair.

You are correct that every one that processes the Work Unit correctly is awarded the same Credit. However, the point that is trying to be made is that the claims made by the computers have a wide spread of values. Though the same total amount of processing is done, the mechanism for calculating the claim does not work properly.

If you process the work unit in 8 hours and claim 15 Cobblestones, and I do it in 4 hours and our answers agree; my claim should be withing 1 Cobblestone of your claim of 15. If my claim is off by more than that ... there is a severe problem ... The "throw away the top & bottom, average the rest" is a bandaid on top of somethint that is not working as expected.

YOu can see similar effects if you change to an optimized client... or a multi-CPU system. The top producing system for SETI@Home is a 64 processor cluster and it calims 0.1 to 0.3 Cobblestones per work unit...

---

Equal pay for equal work seems imminently fair.

You are correct that every one that processes the Work Unit correctly is awarded the same Credit. However, the point that is trying to be made is that the claims made by the computers have a wide spread of values. Though the same total amount of processing is done, the mechanism for calculating the claim does not work properly.

If you process the work unit in 8 hours and claim 15 Cobblestones, and I do it in 4 hours and our answers agree; my claim should be withing 1 Cobblestone of your claim of 15. If my claim is off by more than that ... there is a severe problem ... The "throw away the top & bottom, average the rest" is a bandaid on top of somethint that is not working as expected.

YOu can see similar effects if you change to an optimized client... or a multi-CPU system. The top producing system for SETI@Home is a 64 processor cluster and it calims 0.1 to 0.3 Cobblestones per work unit...

Under no circumstances should the benchmarks be optimized.

The problem with the existing benchmark is that it doesn't handle the variation between different CPU architectures -- something that is incredibly hard to do.

---