First, the optimised clients get less credit per WU due to spending less time on each one. The credits per hour are fairly constant as I understand from other threads.

Second, the first person who returns the result for a WU determines what score that everyone gets.

Third, since optimised clients are faster, guess who determines the score.

Thus everyone else who does not have an optimised client just had their score per hour dropped in about half.

See this WU for details. I do not know if the two lower ones are optimised clients or not, but the higher ones are normal values that I get for most WUs.

Is this logic faulty? I am mainly in it for the science, but I would hate to see the majority affected by the minority. Therefore, I am greatly reducing my cache size so I can get in first to set the value credited to everyone. Even though this may cause my queues to empty fairly often.

---

Second, the first person who returns the result for a WU determines what score that everyone gets.

For seti (other projects may work differently), out of the four results the highest and lowest credit values are discarded and the remaining results averaged. At least that's how I thought it worked. I believe einstein works differently, the other projects I've no idea.

First, the optimised clients get less credit per WU due to spending less time on each one. The credits per hour are fairly constant as I understand from other threads.

Second, the first person who returns the result for a WU determines what score that everyone gets.

Third, since optimised clients are faster, guess who determines the score.

Thus everyone else who does not have an optimised client just had their score per hour dropped in about half.

See this WU for details. I do not know if the two lower ones are optimised clients or not, but the higher ones are normal values that I get for most WUs.

Is this logic faulty? I am mainly in it for the science, but I would hate to see the majority affected by the minority. Therefore, I am greatly reducing my cache size so I can get in first to set the value credited to everyone. Even though this may cause my queues to empty fairly often.

I find that the credit given is a split between the highest and lowest over three different users, I have had units where I claim 26 but get 40 and others where I claim 30 but get 26 and yes I am running an optimised client!
Crikey your in university and you can't figure that out oh well just another engineer in ther making all brain and no common scense.
Dont come to Australia a trades assistant would have you chasing you tail.
BTW the last three lines are in jest only no insult is intended it's just a friendly poke in the ribs, I am a Mechanical fitter / service technician by trade.

---

Second, the first person who returns the result for a WU determines what score that everyone gets.

To assign credit the first three valid results are taken into account, and the middle one is used. In the case you mentioned, the returned results in cronological order were: 15.77, 26.57 and 11.39. So the lowest and highest were taken out (11.39 & 26.57) and the middle one assigned: 15.77

---

There is a significant effect depending on the version of BOINC and whether or not you are running an optimised BOINC with the optimised science app.

The worst case scenario is to use the optimised science app with an unoptimised BOINC since the benchmarks will be low and the client app will be fast leading to very low scores being claimed. If both are optimised then the scores will be somewhat higher but still not as high as stock unoptimised for both. However you should get a higher score per day because of virtually doubling your throughput (for relatively modern intel processors anyway).

It's a bit different if you are still running 4.19 as this version gave artificially high benchmarks anyway (corrected in 4.2x). The sweetest combination for raw scoring power should be an optimised 4.19 BOINC with the optimised science app, I believe.

Your statement about the first WU returned determining the score is incorrect. I believe the lowest claim is always dropped and the score given is some function of what remains.

If you wanted everyone to benefit from client optimisation then you would convince all those who were running optimised clients to run an optimised 4.19 BOINC and to have a 10 day cache and only return their work when the cache was virtually empty. That way they should generally be the last to report back and the three earlier and hopefully somewhat higher scores from non-optimised clients would have already set a higher value which would flow through to the last to report.

Of course this is all tongue-in-cheek :). I'm not seriously suggesting that anyone should do anything like this :).

---

Cheers,
Gary.

Actually, I use optimized science app with unoptimized boinc (4.43) - and claim a little, but not much, less credit than earlier. That small decrease is not enough to affect others (imho and based on my own observations)

---

I think the most important thing is to get the work units done as quickly as possible as long as they are completed correctly. I think the optimised clients are doing that.

Maybe someday someone can run some sort of compiler to optimise on our credit system.

---

Actually, I use optimized science app with unoptimized boinc (4.43) - and claim a little, but not much, less credit than earlier. That small decrease is not enough to affect others (imho and based on my own observations)

Can you mention exactly what Athlon processor you are using? I just had a look at your results and here is a summary (an average of several):-

Nonoptimised: Average Time = 9,500 seconds - - Average claim = 30
Optimised app: Average Time = 7,500 seconds - - Average claim = 23

You seem to be running about 20% faster and claiming about 20% less. Seems fair to me and the science is the big winner.

Here are my results using 4.19 BOINC and the optimised P3 app with an Athlon XP2000+ running overclocked at 10x220 = 2200mHz

Nonoptimised: Average Time = 10,600 seconds - - Average claim = 43
Optimised app: Average Time = 8,400 seconds - - Average claim = 35

Once again about 20% faster and claiming about 20% less.

However the interesting statistic is that your benchmarks are shown as 2048 (FP) / 3413 (Int) whereas mine (4.19) are 2064 (FP) / 5015 (Int). I guess that's why I'm claiming 35 and you are only claiming 23. That's the infamous benchmark bug in 4.19. I believe we would both claim more if we were using optimised BOINCs which would presumably give higher benchmarks. I'm not sure what the available optimised BOINC version actually is but it's neither 4.19 or 4.43. It's somewhere close to 4.30 I think. I wonder if anyone has gone to the trouble of making an optimised 4.19??

---

Cheers,
Gary.

My computer is an Athlon 3200+ slightly overclocked (11.5x200, 2300MHz).

The decrease in claimed credit also seemed fair to me - which was why I don't bother with the optimized boinc cc ;) With the optimized cc, as far as I've read at least, the benchmarks would result in higher claimed credit, which I don't feel is fair - not in my case at least - as claimed credit should be a "faktor" of time spend. If my client claimed the same credit as the unoptimized one, I would feel like I was cheating (or at least trying to) ;)

And yes, we'll have to take cc versions into consideration when comparing claimed credit, as the benchmarks are getting more and more accurate - which is why I support the idea of every once in a while increasing the least accepted cc version ;)

---

Your worst case situation is to have two of the crunchers be optimized clients, or to be optimized and share a WU with a hyperthreaded Pentium 4 cruncher...as in all these cases your two lowest claims (one of wich will be middle) will be fairly low.

---

Exactly. What complicates it further is that SETI seems to be very random in what it claims for credit. A factor of 2 is not uncommon when I look through the various completed WUs. I have examples of claimed credit of 18-38 for one WU and another one with claimed credit of 13-33.

Einstein does the same method (middle of the first 3 WU) to be the granted credit. But the various WU's over there seem to only vary about 20%.

Your worst case situation is to have two of the crunchers be optimized clients, or to be optimized and share a WU with a hyperthreaded Pentium 4 cruncher...as in all these cases your two lowest claims (one of wich will be middle) will be fairly low.

---

I have been wondering about the same, especially when testing optimised versions of boinc and client. I tracked ~150 WU's with two boinc versions and 2-3 different clients on two platforms (Linux/AMP XP 2800+ and Win XP/Pentium-M). What struck me is that the amount of credit claimed per CPU second spent is exactly constant (for the same version of boinc) in 5 decimals. On reflection tis is not surprising at all; it is after all only the boinc version that determines (or rather the benchmark results) how much credit you CLAIM per second spend. So optimisng your boinc client gets you to claim more.

What you get depends on what two others claim; I found that optimised clients on AMD/Linux got me to get much closer to what I claimed. You see the same trend for the Windows XP/Pentium-M platform, but there I get always more than claimed. Again, this is logical -- the benchmark is not affected by optimised clients, but you do finish quicker than previously, so assuming that your peers will have the same speeds as before means you will get more granted than before.

---

OSU Mechanical Engineering:

Try looking at http://setiweb.ssl.berkeley.edu/workunit.php?wuid=16150202

The lowest and highest claimed are not optimized - the two middle ones are one with optimized science app and one with both science app and cc optimized.

Note the order of returned results:

1st 30.46 (unop.)
2nd 24.76 (op s.a.)
3rd 28.98 (op s.a. &cc)
4th 17.54 (unop)

By the time the 3rd was returned, the highest (30.46) and lowest (24.76) was "stripped" and the 28.98 remained - and was the credit granted. Credit was granted before the 4th came in, so the fourth was granted the same amount as the three others.

Roughly the same pattern imerges when I look through other results: the very low claimed credit doesn't come from optimized clients - at least not on the wu's I've been crunching - and on average they don't even pull down granted credit

---

OK just to throw some fuel on the fire here are my Credits for my 840 dual and HT, 4 CPUs. Credit is not the important to me but I know a lot of people need them to keep crunching, so with that said I feel that the benchmark needs a servere over haul. As you can see I claim real low credit but I get anywhere from the same to 4+ times my claimed amount. I claim around 40 for less than 2 mins crunching, for 4 WUs and get around a 100.


66444135 16069438 24 May 2005 23:42:02 UTC 25 May 2005 9:42:25 UTC Over Success Done 6,495.66 10.19 26.18
66444129 16069437 24 May 2005 23:42:02 UTC 25 May 2005 2:26:04 UTC Over Success Done 4,662.64 7.31 36.83
66444113 16069433 24 May 2005 23:42:02 UTC 25 May 2005 9:27:01 UTC Over Success Done 6,389.22 10.02 19.67
66444108 16069432 24 May 2005 23:42:02 UTC 25 May 2005 6:56:25 UTC Over Success Done 6,485.27 10.17 pending
66444105 16069430 24 May 2005 23:42:02 UTC 25 May 2005 5:52:36 UTC Over Success Done 6,588.11 10.34 15.92
66444081 16069427 24 May 2005 23:42:02 UTC 25 May 2005 3:52:13 UTC Over Success Done 6,400.25 10.04 32.02
66444080 16069424 24 May 2005 23:42:02 UTC 25 May 2005 4:04:53 UTC Over Success Done 6,398.39 10.04 33.58
66444047 16069416 24 May 2005 23:42:02 UTC 25 May 2005 4:07:43 UTC Over Success Done 6,498.02 10.19 26.05
66444016 16069410 24 May 2005 23:42:02 UTC 25 May 2005 7:30:00 UTC Over Success Done 6,455.98 10.13 29.72
66443987 16069404 24 May 2005 23:42:02 UTC 25 May 2005 5:42:34 UTC Over Success Done 6,376.13 10.00 27.73
66443984 16069403 24 May 2005 23:42:02 UTC 25 May 2005 2:26:04 UTC Over Success Done 4,662.70 7.31 24.38
66443971 16069397 24 May 2005 23:42:02 UTC 25 May 2005 4:22:05 UTC Over Success Done 6,676.52 10.47 20.27
66443955 16069392 24 May 2005 23:42:02 UTC 25 May 2005 5:52:36 UTC Over Success Done 6,000.14 9.41 25.45
66443923 16069384 24 May 2005 23:42:02 UTC 25 May 2005 11:13:40 UTC Over Success Done 6,384.00 10.02 14.96

---

Semper Eadem
So long Paul, it has been a hell of a ride.

Park your ego's, fire up the computers, Science YES, Credits No.