WHL, this is a moderation warning. Acting deaf against any argument and constantly posting with the sole intent to discredit the project will not be tolerated. Specifically I ask you to refrain from:

1. Calling for optimisation without addressing some of the issues as described eg. here and in other posts from Mats.
2. Saying that high end machines will be dragged down by the credit system without explaining why and how.

---

I am a forum moderator! Am I?

Perhaps Whl is referring to the fact that the credit system is still based upon the BOINC credit claims... and the average thereof. So, I think dcdc is not entirely correct in saying the new system is "without a benchmark". The BOINC benchmark still enters in to it because that is the basis for the credit claims we're averaging together to establish credit per model.

I'm the first to admit I know nothing about OCing a PC. So, if my scenerio wasn't entirely realistic, I apologize. My intent was to spell out clearly what I'm saying, in hopes that you would do the same. I think your original point about people becoming discouraged to run the project is now being clouded over. So perhaps you have more then one point to make?

So yes, Whl, please inform us about how high-end systems have a credit disparity. Can you provide an example host ID? Is the high-end system a Mac PPC?

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

When you say "averaging" - it implies that a top scoring credit/model machine will have its score reduced, while the lowest scoring credit/model machines will have their score increased.

Ingleside touched on the topic here. Ingleside pointed out the effect that 10% overclaiming on credit would have, and the effect the 12.7% Mac and Linux crowd would have on an average. The effect of all the underclaiming P4s wasn't dealt with.

I did a limited comparison of P4 vs Athlon 64, P4 on Windows vs P4 on Linux, and some Macs in this thread.

I'm having trouble finding the post by David Kim where he mentioned using a correction factor on the credits/model, which I assume was to take care of the effect of all the underclaiming P4s. (Was that discussion on the Ralph board?)

Given that Athlons in general or Athlon 64s in particular were getting the best benchmarks with the standard client in the past, and my Athlon 64 was getting 1.15 times the credit that I used to under the old credit system using the standard client, then it seems as if the correction factor being applied is more than adequate to deal with the underclaiming P4s. I'm using 24 hour WUs, so by the time I turn one in, my score/model should be close to the average for the WU.

---

(Was that discussion on the Ralph board?)

yes

sorry can't chat, putting new machine together. errr...ahhh, installing "repair parts". LOL

WHL, this is a moderation warning. Acting deaf against any argument and constantly posting with the sole intent to discredit the project will not be tolerated. Specifically I ask you to refrain from:

1. Calling for optimisation without addressing some of the issues as described eg. here and in other posts from Mats.
2. Saying that high end machines will be dragged down by the credit system without explaining why and how.

Great, is'nt it. Because you dont understand what I've said, I get a warning ?

---

When you say "averaging" - it implies that a top scoring credit/model machine will have its score reduced, while the lowest scoring credit/model machines will have their score increased.

Ingleside touched on the topic here. Ingleside pointed out the effect that 10% overclaiming on credit would have, and the effect the 12.7% Mac and Linux crowd would have on an average. The effect of all the underclaiming P4s wasn't dealt with.

I did a limited comparison of P4 vs Athlon 64, P4 on Windows vs P4 on Linux, and some Macs in this thread.

I'm having trouble finding the post by David Kim where he mentioned using a correction factor on the credits/model, which I assume was to take care of the effect of all the underclaiming P4s. (Was that discussion on the Ralph board?)

Given that Athlons in general or Athlon 64s in particular were getting the best benchmarks with the standard client in the past, and my Athlon 64 was getting 1.15 times the credit that I used to under the old credit system using the standard client, then it seems as if the correction factor being applied is more than adequate to deal with the underclaiming P4s. I'm using 24 hour WUs, so by the time I turn one in, my score/model should be close to the average for the WU.

There is no such kind of "averaging". What kind of "averaging" are you referring to? There is a value established for credit/decoy for each WU. Let's for a moment put aside how this value is established. Once this value is established it will determine how much credit you receive compared to other hosts, which are slower or faster. So there won't be any decrease or increase for slower or higher machines. Let's say the value is 1credit/decoy. If your computer is very, very slow and can just do one decoy per day it receives 1 credit. If your computer is super, super fast and can doe 10.000 decoys per day it receives 10.000 credits. Let's say the value is 10credits/decoy, then you have 10 to 100.000. In any case the faster comp gets 10.000 the credit of the slower host, since he computes 10.000 the work of the slower host. So there is a linear scale which will accurately reflect the difference between the hosts.

Now back to how this value is established. Here the reported benchmarks, the under- und overclaimer come in play. There are a lot of inaccuracies in the process of establishing the value but due to the massive sampling all averages out more or less (+-20%). Here you can apply a correction factor to keep cross project parity or not. The important point is, it does not influence the intra-project-parity how the credit/decoy ratio is establised. The difference between the hosts will always reflect the true capabilites according to real work done, even if the absolute number will differ.

Their is one caveat in the actual process used and that is, that a rolling average is used which will at least in the beginning vary to some extent. In practice it does not seem to have much distorting influence since it will average out over time but theoretically this is a weak point. Therefore I stronlgy back the idea of pending credits until a reliable credit/decoy ratio can be established based on perhaps 20.000 decoys reported.

Okay this is long and complicated, the findings are:

1. The system of awarding fixed credit/decoy does truly reflect the difference in actual work done between different hosts with no penalties for any hosts.
2. Due to the process how this ratio (credits/decoy) is established there are variations for early results and the total amount of credit is also affected according to the average of claimed credits of all hosts.
3. To assure intra-project-fairness and keep variations below 1% one would need to implement a pending period to get a reliable credit/decoy value.
4. To keep cross project parity one would need to revise the average granted credit from time to time and apply if neccesary a correction factor (this is not needed for intra project parity).

Any objections? ;-)

WHL, this is a moderation warning. Acting deaf against any argument and constantly posting with the sole intent to discredit the project will not be tolerated. Specifically I ask you to refrain from:

1. Calling for optimisation without addressing some of the issues as described eg. here and in other posts from Mats.
2. Saying that high end machines will be dragged down by the credit system without explaining why and how.

Great, is'nt it. Because you dont understand what I've said, I get a warning ?

You got a warning for posting with a negative attitude. Although a negative attitude is no violation of whatsoever it becomes a pain if you do it over many weeks on many occasions with dozens of posts, which all have the same message: "this project sucks". We don't need that.

---

I am a forum moderator! Am I?

I have 127 posts since December 2005. 128 now ?

P.S. Your intervention was unnecessary in the first place. All you have done is broken up a discussion that was going along fine and taken it off at a tangent for no apparent reason other than your opinions about my attitude. (Which was'nt the reason you gave in the first place BTW).

---

Looks like key info. resides in a deleted thread. Rolling back through David Kim's posts You see he posted:

It's a running average, so the first result gets the standard claimed credit, the second gets the average of the two and so forth.

[edit] all the more reason to post such info. in specific read-only threads where one can look for formal announcement info. of such details.

---

Add this signature to your EMail:
Running Microsoft's "System Idle Process" will never help cure cancer, AIDS nor Alzheimer's. But running Rosetta@home just might!
https://boinc.bakerlab.org/rosetta/

[quote] When you say "averaging" - it implies that a top scoring credit/model machine will have its score reduced, while the lowest scoring credit/model machines will have their score increased.


There is no such kind of "averaging". What kind of "averaging" are you referring to? There is a value established for credit/decoy for each WU.

[...]
2. Due to the process how this ratio (credits/decoy) is established there are variations for early results and the total amount of credit is also affected according to the average of claimed credits of all hosts.

3. To assure intra-project-fairness and keep variations below 1% one would need to implement a pending period to get a reliable credit/decoy value.

The comments about the high credit lottery which have been going on for the last couple of weeks (getting a credit/decoy higher than average by being one of the first few hosts to submit a particular WU while using an optimized client) is based on the idea that some form of averaging is happening.
When an optimized client turns in 10 models and asks for 60 credits, or a Duron turns in 1 model and asks for 6 credits and they're followed by a fast system that turns in 20 models and asks for 20 credits, it was my understanding that the first few hundred models turned in would get a fluctuating amount of credit/model until there was enough models turned in that we'd get near an average credit/model.

Those that turn in high credit/model values would get less than requested, while those that turn in low credit/model values would get more than requested because they're being averaged.

How is this not a form of averaging?

And if there's a noticeable fluctuation in credit/model for the first 100 or 1000 models turned in, rather than just theoretical, then perhaps we can get David Kim to average out the whole 10k, 100k, or more decoys that are turned in.

---

By reading your posts, WHL, it seems to me you are calling for a credit system, which does not award credit according to the actual work done, but according to the potential work that a specific processor could achieve.............

Missed your post in the confusion.

If I am allowed to say this without getting banned by MOD.DE ? This new credit system does'nt reflect the actual work done either. We have a situation now where lower end machines are getting higher credits than they would otherwise have got and higher end machines are getting lower credits than they would otherwise have got. In other words, the higher end machines are dragging the lower end machines up and the lower end machines are dragging the higher end ones down.

Almost like communism in a way. And it looks like we may be getting our own version of Pravda her now too. ;-)

---

By reading your posts, WHL, it seems to me you are calling for a credit system, which does not award credit according to the actual work done, but according to the potential work that a specific processor could achieve.............

Missed your post in the confusion.

If I am allowed to say this without getting banned by MOD.DE ? This new credit system does'nt reflect the actual work done either. We have a situation now where lower end machines are getting higher credits than they would otherwise have got and higher end machines are getting lower credits than they would otherwise have got. In other words, the higher end machines are dragging the lower end machines up and the lower end machines are dragging the higher end ones down.

Almost like communism in a way. ;-)

This is not true WHL! Please reread this post. The "averaging" takes place not between higher end machines and lower end machines but between overclaimers and underclaimers. A slow host using the 5.5.0 client will drag the average granted credit up, while a high end machine using Linux and a stock client will drag the average granted credit down. Your phrase "than they would otherwise have got" refers to a scenario in which the higher end machines use the "overclaiming" 5.5.0 credit and slower host use the "underclaiming" stock client. It might well be the reverse in some cases.

[quote] When you say "averaging" - it implies that a top scoring credit/model machine will have its score reduced, while the lowest scoring credit/model machines will have their score increased.


There is no such kind of "averaging". What kind of "averaging" are you referring to? There is a value established for credit/decoy for each WU.

[...]
2. Due to the process how this ratio (credits/decoy) is established there are variations for early results and the total amount of credit is also affected according to the average of claimed credits of all hosts.

3. To assure intra-project-fairness and keep variations below 1% one would need to implement a pending period to get a reliable credit/decoy value.

The comments about the high credit lottery which have been going on for the last couple of weeks (getting a credit/decoy higher than average by being one of the first few hosts to submit a particular WU while using an optimized client) is based on the idea that some form of averaging is happening.
When an optimized client turns in 10 models and asks for 60 credits, or a Duron turns in 1 model and asks for 6 credits and they're followed by a fast system that turns in 20 models and asks for 20 credits, it was my understanding that the first few hundred models turned in would get a fluctuating amount of credit/model until there was enough models turned in that we'd get near an average credit/model.

Those that turn in high credit/model values would get less than requested, while those that turn in low credit/model values would get more than requested because they're being averaged.

How is this not a form of averaging?

And if there's a noticeable fluctuation in credit/model for the first 100 or 1000 models turned in, rather than just theoretical, then perhaps we can get David Kim to average out the whole 10k, 100k, or more decoys that are turned in.

I agree with you, that there should be used an average after 10k or 100k returned decoys. I would even stop than and fix the credit/decoy ratio. This would ensure that everybody gets exactly the same credit/decoy regardless when he returns in a result.

So far nobody could show that he can get significantly higher credits (>5%) with some techniques but it would be helpful to convince David Kim of activating the pending feature if somebody could.

However this averaging between all hosts for the ratio credit/decoy has nothing to do with higher end machines are dragged down and lower end machines are dragged up. Overclaimers are dragged down and underclaimers are dragged up. The term overclaim and underclaim refers in this case not to a just or fair measure but just to the relationship of claimed credits and actual work done.

This new credit system does'nt reflect the actual work done either. We have a situation now where lower end machines are getting higher credits than they would otherwise have got and higher end machines are getting lower credits than they would otherwise have got. In other words, the higher end machines are dragging the lower end machines up and the lower end machines are dragging the higher end ones down.

Do you have some facts to back up this? It doesn't get true by repetition alone.

---

I can see where Whl is coming from. It all depends on whether the benchmarks (which are still used for the claimed credit, and therefore affect the average) actually reflect the performance of each machine.

Put simply would a machine that has twice the benchmarks produce exactly twice as much work?

---

There is NO perfect benchmark software available, NONE, Nada, Zip. Some are better than others at certain things. some are even specifically written to favor one product so marketing can claim this or that.

However, In Boinc benchmark system the faster machines and slower machines should be claiming "nearly" the same amount of credit per wu.

The formula for Claimed Credit is ((Whetstone + Dhrystone)x Cpu seconds)/1728000. If you double the benchmark by having a fast machine you also cut cpu seconds in 1/2.

A=Whetstone
B=Dhrystone
C=Cpu seconds

so the formula is:

((A+B)xC)/1728000=CC

now let's double the benchmark and cut the time in half and we see they are identical:

((A+B)xC)/1728000=((2A+2B)x1/2C)/1728000=CC

Now you go ahead and insert any value for A,B, and C and you'll see what I mean.

I don't think anything is being dragged down. If you look at a larger sample of WU's you see the new averaging system actually raises credit slightly when compared to the standard boinc benchmark system.

Now if you're using something other than the official boinc benchmark system, which alters A, B, and/or C (above), then I can see where you might view it as being dragged down.

Tony, what you are showing there is the old BOINC credit system without averages applied. If you use this as part of the new system and apply averages, something has to go up and something has to go down.

---

---

"I know that you believe you understand what you think I said, but I'm not sure you realize that what you heard is not what I meant." R.M. Nixon

That is probably because you were close to first in with that workunit, with an overclaiming client first in (which would have been awarded what it claimed). My team mate was awarded 2 points for a valid 24 hour workunit (on an A64 4000+ if I remember correctly), Which does'nt seem to make any sense at all, even if you take averages into account.

---

That is probably because you were close to first in with that workunit, with an overclaiming client first in (which would have been awarded what it claimed). My team mate was awarded 2 points for a valid 24 hour workunit (on an A64 4000+ if I remember correctly), Which does'nt seem to make any sense at all, even if you take averages into account.

I agree 2 credits for 24 hours on any system seems LOW. I get approx 1.5-2/hour on a celeron 500. Perhaps you could highlight that WU for management to examine and figure out what happened?