I was wondering if anyone can explain to a simple person like me why this happened.

Validate state Valid
claimed credit 42.8223506579567
Granted credit 28.8604524810838

Is this saying i didnt complete the full W/U or something?

First off, I should probably post the link to where the FAQs are located:

http://setiboinc.ssl.berkeley.edu/sah/related.php

Second, from looking at the numbers I've been getting it seems that after three hosts return a unit, all three hosts get credit equal to the middle computer's claim. In that respect, everyone who processes that work unit gets the same credit for it. I guess they chose the middle number simply because it was the middle value rather than an extreme.

> First off, I should probably post the link to where the FAQs are located:
>
> <A> HREF="http://setiweb.ssl.berkeley.edu/sah/related.php">http://setiboinc.ssl.berkeley.edu/sah/related.php[/url]
>
> Second, from looking at the numbers I've been getting it seems that after
> three hosts return a unit, all three hosts get credit equal to the middle
> computer's claim. In that respect, everyone who processes that work unit gets
> the same credit for it. I guess they chose the middle number simply because it
> was the middle value rather than an extreme.
>
>



I am SO tired of outcome-based education's dumbing down of everything. Seti just lost 3 CPU's (and those of my friends that I can convince) to Folding@home.

> I am SO tired of outcome-based education's dumbing down of everything. Seti
> just lost 3 CPU's (and those of my friends that I can convince) to
> Folding@home.

Bye. :)

"All users that have returned valid results for the work are then granted the credit that is equivalent to the lowest claimed." > I am SO tired of outcome-based education's dumbing down of everything.
> Seti
> > just lost 3 CPU's (and those of my friends that I can convince) to
> > Folding@home.
>
> Bye. :)
>
> <a> href="http://www.boinc.dk/index.php?page=user_statistics&userid=91863">
>

> > Second, from looking at the numbers I've been getting it seems that
> after
> > three hosts return a unit, all three hosts get credit equal to the
> middle
> > computer's claim. In that respect, everyone who processes that work unit
> gets
> > the same credit for it. I guess they chose the middle number simply
> because it
> > was the middle value rather than an extreme.
> >
> >
>
>
>
> I am SO tired of outcome-based education's dumbing down of everything. Seti
> just lost 3 CPU's (and those of my friends that I can convince) to
> Folding@home.
>

First of all, there is a very VALID reason why all three are awarded the middle value. Without this feature, it is possible to exploit the credit system in such a way as to give yourself an arbitrarily high number of credits for each work unit. I am NOT gonna go into the details of how the exploit works, but Berkeley put this feature in to prevent it. So many of the 'oddities' that are present in BOINC are the direct result of Berkeley's experience with cheaters on the S@H-Classic project. Blame the cheaters, not Berkeley.

Secondly, there are 4 possible ways to allocate credit on a 3-work-unit quorum system:

1. Give everyone the credit they claimed.
2. Give everyone the maximum credit claimed by the 3 hosts.
3. Give everyone the middle credit.
4. Give everyone the lowest credit.

Analysis:

#1 is wide open to the exploit.

#2 is only marginally better than #1. In #2, all three people would get the bogus value of credits. But, assuming that only a small number of participants would try this exploit, and knowing that the work unit assignment is somewhat random, this is STILL of great benefit to those that would do the exploit.

#4 is the way that Berkeley initially decided to proceed. For credit to be affected, on average a LARGE percentage of the participants would have to be using the exploit, and for it to affect every unit, everyone would have to be doing it. The Alpha/Beta testers objected to this, especially since there was a bugged Sun-Solaris client that had several sun computers claiming some rediculously small (on order of 0.04) amount of credit.

#3 is the compromise that Berkeley made to appease us beta testers. The anti-exploit safeguards on this are only slightly weaker than on #4 (it still requires quite a large percentage of the people using the exploit for any benefit to accrue). Plus, there is the 'fairness' angle. For every time someone loses credits on a work unit, someone gains. Odds are that this gain/loss will average (over many work units) to something very near zero.

It is sad that Berkeley was forced (by people that are immature enough to try these cheats/exploits) to do this, but it is for the good of the project.

Sithehenn, if you (or anyone else) are unwilling, in light of this anti-cheating measure, to participate in BOINC, then I wish you well in whatever you decide to do instead.

Be well, and have a nice day.
------------
KWSN-MajorKong
KWSN Forum Admin (retired)
http://www.kwsnforum.com

S@H participant since May 28, 1999 (other acct.)
BOINC Beta Tester since Nov 19, 2003

Jeeze, you missed a biggy....

Give EVERYONE 1 CREDIT for a WU! (as a way of tracking progress). Kind of like, Seti Classic!

This whole claimed/pending crap is just that for most folks (all 200,000 of us).

Right now, I have no clue as to how much work I've done in BOINC. I might have claimed 500 whatevers, been "granted" 200 whatevers, and have 100 pending whatevers! The back end can track this, but at the end of the day, don't mean anything to the resource base known as "users"

What was wrong with the seti 1 display of "x WU's and y amount of CPU time"?

Doesn't change squat on the "validity of data" or "stopping cheaters", but only presents data in a way that users understand!

Who cares is user XYZ claims more CPU as they are trying to "fool" the system. There stats will show "X WU's with 9900 years of CPU time", but it's "X" that will be seen by everyone else. The ONLY reason that someone would inflate their CPU time, is that it's the measure of what's being done! If it were 1 WU = 1 Credit, inflating CPU time wouldn't buy the "bad folks" anything!

1 WU = 1 credit! Why not?

even with multiple projects, 1 Seti WU, 1 predictor WU could show up on a PER PROJECT basis! (like the current "whatevers") So I have 100 Seti WU's and 5000 predictor WU's, means much more than 273.987 Seti Credits and 283.765 Predictor credits to most users!

Right now, with one project, having credits move from pending to granted can take 10 days or so. And this is not a startup issue, as a new WU in Sept will get sent to the next 3 requesters. Therefore sept+10days will be the deadline!

Unless Seti/BOINC plans on "recycling" WU's when they run out of work! (oh... we know seti would NEVER run out of work!) :)


> First of all, there is a very VALID reason why all three are awarded the
> middle value. Without this feature, it is possible to exploit the credit
> system in such a way as to give yourself an arbitrarily high number of credits
> for each work unit. I am NOT gonna go into the details of how the exploit
> works, but Berkeley put this feature in to prevent it. So many of the
> 'oddities' that are present in BOINC are the direct result of Berkeley's
> experience with cheaters on the S@H-Classic project. Blame the cheaters, not
> Berkeley.
>
> Secondly, there are 4 possible ways to allocate credit on a 3-work-unit quorum
> system:
>
> 1. Give everyone the credit they claimed.
> 2. Give everyone the maximum credit claimed by the 3 hosts.
> 3. Give everyone the middle credit.
> 4. Give everyone the lowest credit.
>
> Analysis:
>
> #1 is wide open to the exploit.
>
> #2 is only marginally better than #1. In #2, all three people would get the
> bogus value of credits. But, assuming that only a small number of
> participants would try this exploit, and knowing that the work unit assignment
> is somewhat random, this is STILL of great benefit to those that would do the
> exploit.
>
> #4 is the way that Berkeley initially decided to proceed. For credit to be
> affected, on average a LARGE percentage of the participants would have to be
> using the exploit, and for it to affect every unit, everyone would have to be
> doing it. The Alpha/Beta testers objected to this, especially since there was
> a bugged Sun-Solaris client that had several sun computers claiming some
> rediculously small (on order of 0.04) amount of credit.
>
> #3 is the compromise that Berkeley made to appease us beta testers. The
> anti-exploit safeguards on this are only slightly weaker than on #4 (it still
> requires quite a large percentage of the people using the exploit for any
> benefit to accrue). Plus, there is the 'fairness' angle. For every time
> someone loses credits on a work unit, someone gains. Odds are that this
> gain/loss will average (over many work units) to something very near zero.
>
> It is sad that Berkeley was forced (by people that are immature enough to try
> these cheats/exploits) to do this, but it is for the good of the project.
>
> Sithehenn, if you (or anyone else) are unwilling, in light of this
> anti-cheating measure, to participate in BOINC, then I wish you well in
> whatever you decide to do instead.
>
> Be well, and have a nice day.
> ------------
> KWSN-MajorKong
> KWSN Forum Admin (retired)
> http://www.kwsnforum.com
>
> S@H participant since May 28, 1999 (other acct.)
> BOINC Beta Tester since Nov 19, 2003
>

Hi all,

I have tried to read all the info I can find on the Credit system - but I'm still a little confused.

The arguments voiced in this thread seem to argue about the value and assignment methods. One suggestion for 1 credit per WU would be the best if it wasn't for the fact that BOINC has vastly differing WU sizes.

Which leads me on to my point: Do Overclockers get penalised?

(not real values - just made them up to demonstrate the point)

For example, 1 WU requires 50 billion calculations to complete. A normal P4-2Ghz takes 4 hours to complete it, and would gain 35 credits for this work.

A o/c's AthlonFX53 can do the same work in 1 hour 25 mins, so as it's cpu time was much smaller, so it would only be awarded 15 credits for the work.

This calculation of CPU time totally ignores the power of the computer doing the work. I think the only serious flaw in the system is SETI/BOINC prefers people to use old slow machines rather than new top-spec machines, and will reward them more for doing so.

In this argument - I have not ever seen one suggestion that maybe each WU should be classified a credit value by SAH BEFORE it is sent out then regardless of who processes it, or if someone tries to cheat on the CPU time, it will only be worth what SAH think it is worth.

I joined SETI because I love the science, love fast computers, and love competition and challenges. I want to reach the top 5% on Classic and achieved it on a fairly level playing field. I don't know what the motivation is with BOINC to build and dedicate the best Silicon available to a project which doesn't seem to want it...

What is with that???

------------------------------------------------
Once you have ruled out the impossible, everything else, however improbable, is possible!
A.C. Doyle.

> For example, 1 WU requires 50 billion calculations to complete. A normal
> P4-2Ghz takes 4 hours to complete it, and would gain 35 credits for this
> work.
>
> A o/c's AthlonFX53 can do the same work in 1 hour 25 mins, so as it's cpu time
> was much smaller, so it would only be awarded 15 credits for the work.

Your example fails to take into account the benchmark. The faster unit will have a higher benchmark score than the slower unit. Shorter process time x higher benchmark should yield the same point value as longer process time x lower benchmark.

If all were perfect all 3 systems would request the same amount of credit for every workunit, but too many things effect the minute to minute operation of the computer for it to be that stable. However, the requested credits should still be very close (actually closer than they usually are in reality) on all 3 systems that do the workunit.

> What was wrong with the seti 1 display of "x WU's and y amount of CPU time"?

Agree completely.

Users basically need not massive sophisticated statistics (especially when is not working or temporary disabled). Classic stats was much logical and pure clear.


MC

AZ Woody: Your suggestion would cause a lot of people to only participate in projects with 'small' work units. I think you underestimate how much some people do this for the credits alone. And "500 Work units" looks better than "100 Work units", no matter what project you are doing them under. You are also failing to take into account a feature of BOINC which doesn't appear to have been used yet. Different computers will be assigned different sized work units, based on their computing power. So even within individual projects, "1 WU" could be meaningless in terms of credit. For BOINC to be viable there MUST be an 'independent' unit of credit based on the computing power of the computer doing the work. I think they still have a few things to tweak in their benchmarking code so that credit matches up better between different CPUs, but the theory behind it is solid.

Ah - I didn't know the benchmark was used in credit allocation.

Hmmmm...

So you saying that if I fill my machine with Dry Ice, and O/c it to 4Ghz - run the benchmark, then set the computer back to normal. Every time I do a WU it will think my computer has been running at 4Ghz for the whole WU?

I have not managed to get any SETI WU's yet, but have completed a few the Predictor WUs. My score for all of these WU's was much lower than most other peoples, varying by as much as 50%.

Another point is, I use a MSI motherboard with CoreControl. This app dynamically varies the FSB and Voltages of the mainboard during operation to give you the best possible performance without going unstable. Therefore my Benchmark will never be accurate...

I guess the problem with this system is that it is seen to be unfair, and that is the thing that will REALLY piss people off. Now, obviously, SETI classic was unfair. Each work unit had a different size and took different about of cpu time etc - but people just saw 1 WU = 1 credit. Really easy, and so it was SEEN TO BE FAIR.

The current system might actually be better than classic, but it is not SEEN that way...

My opinion is that anything relating to time should be discarded when it comes to scoring credits - it shouldn't have anything to do with it (other than an interesting stat). Why should how long it takes my computer have anything to do with the result returned... The result is the result and has the same value to SETI regardless of what type of machine that returned it!

Each WU should be evaluated as to it's complexity and difficulty on creation at SETI. Once rated, a credit score should be assigned, and then offered out for calculation.

People with older computers could opt for simple low scoring WU's so their computer doesnt take 3 weeks to complete one wu, where people with their own personal nitrogen-cooled Cray can tackle the bigger higher-scoring wu's.

This way - it doesnt matter what computer you use to run the task on, the credit is the same. And the only time-concerns are yours, and not BOINC or SETI's.

This idea levels the playing field somewhat, and makes it very fair for everybody (well - in perception at least ;o) I, personally, would be a lot happier with this system!


------------------------------------------------
Once you have ruled out the impossible, everything else, however improbable, is possible!
A.C. Doyle.

> Jeeze, you missed a biggy....
>


Woody:

Jeeze, YOU missed a biggy!

Putting aside for now the planned cross-project stats unification (S@H + P@H + etc.), there is another reason for a computation-based stat. The S@H project itself will have multiple work unit types (with vastly different computation requirements). Computation based stats (the 'Cobblestone') are needed to track this. It is a much easier measure of contribution to have 3256 'credits' on S@H than it would be to have (337 S@H-Type A, 62 S@H-Type B, 3 S@H-Type C, etc.).

Now they COULD index the various types (for instance, 1 type c = 11.2 type a), but, essentially, that is what they have done. The BOINC credit system factors in BOTH the CPU speed, AND the amount of CPU time required. Its not perfect (yet), but it is NECESSARY.

As you say, S@H-Classic is nearly out of data. New data will, almost certainly, be in new formats. New formats will require new science code. Under the old S@H-Classic paradigm, each new science core would have required its own, independant project (software framework AND hardware infrastructure), and have its OWN seperate 'stats'. The end of 'one-size-fits-all' S@H is near. For instance, what about the 8-bit reobservation data? The entire point of BOINC is to keep each S@H 'project' from having to re-invent the wheel, and to centralize all of them into one place. Change is necessary for S@H to continue. Technology changes. Life is ALL about change. Deal with it.

It seems that, all too frequently, whenever someone tries to explain a BOINC feature to someone new to BOINC, YOU chime in whineing about how it all should still be JUST LIKE S@H-Classic. If you like S@H-Classic so much, why don't you just continue to run THAT project until it goes dark, then go find something ELSE to do with your time and CPUs. Your whineing about how 'they' are changing up your 'favorite toy' does NOT help people to adapt to BOINC. You have repeatedly insulted the BOINC developers and the project staff at Berkeley (not to mention quite a number of your fellow project testers and participants). I am sure that, since you called them a bunch of 'Chimps', the BOINC developers are not going to pay much attention to ANY suggestion or feature request you may have.

If you wish to run BOINC/S@H, great! But, please, refrain from whineing about how its not like S@H-Classic down to the last little detail. If, for whatever reason, you do not wish to participate in BOINC/S@H, then please find something else to work on. Your acting like a whineing little brat is not helpful, nor is it appreciated. Your antics here (and on the S@H-Classic forums) are makeing you quite the laughing stock in other places. I have heard about you and your postings from several different people, independently, when discussing the BOINC project (both online, AND in person). Your behavior since launch of BOINC/S@H is giving both yourself and the entire project a bad name.
------------
KWSN-MajorKong
KWSN Forum Admin (retired)
http://www.kwsnforum.com

S@H participant since May 28, 1999 (other acct.)
BOINC Beta Tester since Nov 19, 2003

> Computation based stats (the 'Cobblestone') are needed to
> track this.

Why? You can estimate how many calculations would be required to complete a particular WU, and there fore assign a credit value. When a computer finishes this WU, they earn the pre-assigned value. This does not require ANY knowledge of what CPU it is running on and how fast it is!

> It is a much easier measure of contribution to have 3256
> 'credits' on S@H than it would be to have (337 S@H-Type A, 62 S@H-Type B, 3
> S@H-Type C, etc.).

I think you missed the point - I didn't mean something like this. Each WU is assigned a calc value, e.g. GigaCalcs.

WU001 = 75 G.calcs
WU002 = 5.1 G.calcs
WU003 = 127 G.calcs
WU004 = 15.2 G.calcs
WU005 = 347 G.calcs
WU006 = 1.7 G.calcs
WU007 = 43 G.calcs

So, I then configure my P3-550 to accept WU between 1-20 GC's because I dont want to have WU's waiting more than 2 weeks, but my O/C'd AthlonFX53 can handle anything, so I choose the high value calcs, say 100+ GC's.

1 GC = 1 Credit.

Therefore, you computer has to make 1,000,000,000 calculations to earn 1 credit.

This totally abstracts the credit system from CPU speed or Time, yet speed and time are used to allocate the WU's. This seems to be a fair system.

If I go down the shop, and want to buy some tomatos - it costs the same, regardless of how fast I earn my salary, and how much I make!


------------------------------------------------
Once you have ruled out the impossible, everything else, however improbable, is possible!
A.C. Doyle.

> Why? You can estimate how many calculations would be required to complete a
> particular WU, and there fore assign a credit value. When a computer finishes
> this WU, they earn the pre-assigned value. This does not require ANY
> knowledge of what CPU it is running on and how fast it is!

This is a good suggestion and I think they probably considered it however it still has one big flaw. Cheaters can still gain credit by returning false results. With the current system, not only is cheating made more difficult by the use of digital keys and signatures but the MOTIVATION to cheat is removed since even if you claim 5 million credits for your work unit, you won't get it. I agree that the pending credit system is a bit cumbersome and may very well frustrate many users however you have to admire the unique way which they came up with to solve the problem of cheaters which was a *HUGE* issue in seti-classic a year or two back. Many people got even more ticked off about that situation than now with the startup problems going on. I believe many people left the project because they felt like their work wasn't appreciated because the cheaters weren't being dealt with correctly. I still get shivers thinking about some of the posts on the forums back then...

I'm hoping once the project gets up and going for good, the wait between claimed and granted credit will be minimized as people start processing more consistently. They could possibly also implement algorithms to send the same work unit to computers which would complete them within similar timeframes. Just hoping on that last one...

> I think you missed the point - I didn't mean something like this. Each WU is
> assigned a calc value, e.g. GigaCalcs.

For most projects it is extremely difficult to predict how many GigaCalcs a particular workunit will use, and if it can be predicted it will be more unreliable than using benchmarks and CPU time on the contributer's computers. Actually running the WU would give you that number, but if every WU was run on the servers before sending them out there would be no reason in sending them at all, right?

What is a Cobblestone?
It's 1 day's work on a reference computer that is running something around the equivalence of 100MHz - you can get the exact specs from the docs.
So when you get 30 CS, you have contributed what equals a month's work for this reference computer.

I think this is a pretty nice way to measure it, isn't it? And pretty easy to understand?

@Nicholas

Under the science proposed for BOINC, the only method of calculating how many "gigacalcs" would be required for a unit is to run it. If UCB run all the units to allocate them a score, why do they need us?

@everyone complaining about Cobblestones

UCB is doing this project to search for evidence of extra terrestrial life, not to give us something to do. The "scores" are just there to add fun. They are not the point of the project. Please don't forget that.

@anyone who says SETI 1 was fair

Rubbish. Utter rubbish. Cheating was rampant so the scores were unfair. Many "cheat" units were processed incorrectly - not contributing to the science - also not fair. See my point above - why are we all doing this?

@anyone insulting the dev and project team

They are working damned hard. Can you do better? If you can, please sign up. If you can't - please shut up. Sorry to be rude but I don't feel calling someone who is working hard to solve your problems a "chimp" is polite, therefore we've lost even the decency to debate the serious issues here politely :(

Are we really going to lose sight of our human decency and the purpose of the project over a "WU" (300k+ of bits and bytes in cyberspace) or a "cobblestone" (similar but smaller)? If you are in this purely for cobblestones then I guess this project is not for you. Sorry. Bye. Find one that is.

> UCB is doing this project to search for evidence of extra terrestrial
> life, not to give us something to do. The "scores" are just there to
> add fun. They are not the point of the project. Please don't forget
> that.

If only life were so simple. If UCB are the only people who count in this project - why do they need us? Oh yes - becuase we donate millions $$$ of computer time free of charge!!! Therefore, if they want to keep us sweet, I guess respecting our part in this project, and our viewpoints might help!!!

> They are working damned hard. Can you do better? If you can, please
> sign up. If you can't - please shut up. Sorry to be rude but I don't
> feel calling someone who is working hard to solve your problems a
> "chimp" is polite, therefore we've lost even the decency to debate
> the serious issues here politely :(

Here I wholeheartedly agree... These guys are working bloody hard to resolve these problems... I think questions should be raised regarding the project management, but this is not the Dev's fault! Maybe they're called "chimps" because they're paid peanuts? ;o)))

> This is a good suggestion and I think they probably considered it
> however it still has one big flaw. Cheaters can still gain credit
> by returning false results. With the current system, not only is
> cheating made more difficult by the use of digital keys and signatures
> but the MOTIVATION to cheat is removed since even if you claim 5
> million credits for your work unit, you won't get it.

The result verification system would not change in my idea. I agree that verifying each others results is a sublime idea! And as SETI would set the WU value too - it would be as cheat-proof as the current system. The only change I was suggesting was to the way credit was allocated.

> For most projects it is extremely difficult to predict how many
> GigaCalcs a particular workunit will use, and if it can be
> predicted it will be more unreliable than using benchmarks
> and CPU time on the contributer's computers.

Not sure about this. We are not asking the computer to calculate EXACTLY how many calcs it would take to get the exact result, but a rough estiamtion. A simple formula could be used, based on experience with the Cobblestone Control Machine.

This is the only area of the idea which I cannot be sure of. The inaccuracy in the pre-processed WU value would have less than the inaccuracy in the current post-processing value. I'm not sure this would be the case... I'll need to think about this one so more Janus! ;o)))

------------------------------------------------
Once you have ruled out the impossible, everything else, however improbable, is possible!
A.C. Doyle.

> If only life were so simple. If UCB are the only people who count in this
> project - why do they need us? Oh yes - becuase we donate millions $$$ of
> computer time free of charge!!!

Surely the key word is "donate" as in "give". If I "give" UCB some computer time, I don't expect anything for it. If I didn't get one e-mail from an automated database anually saying "thanks for your continued support", personally I wouldn't really care. I CHOOSE to give. I wasn't promised anything in return. And that to me is the heart of the matter - it's up to me to take part or not under whatever rules and environment the project sets.

>Therefore, if they want to keep us sweet, I guess respecting our part in this
>project, and our viewpoints might help!!!

The work so far shows that the team IS listening to us, but they will always have their own "red lines" - immovable rules which apply to BOINC and its sub-projects. Surely we can't expect to have our own way in all things? Especially as a lot of the posts on these forums at the moment are, I think, a release of frustration at not being able to up & download units rather than reasoned response or logical argument.

>
> Not sure about this. We are not asking the computer to calculate EXACTLY how
> many calcs it would take to get the exact result, but a rough estiamtion. A
> simple formula could be used, based on experience with the Cobblestone Control
> Machine.
>
> This is the only area of the idea which I cannot be sure of. The inaccuracy
> in the pre-processed WU value would have less than the inaccuracy in the
> current post-processing value. I'm not sure this would be the case... I'll
> need to think about this one so more Janus! ;o)))
>

Many of the projects (possibly not SETI but who knows) thinking of moving to BOINC expect the wu processing to be multi-branched and conditional. How can all projects estimate how much processing a wu would take? We don't KNOW that units from a certain angle range will contain a signal, so how could the estimate account for the extra processing involved? What if the science were changed to re-analyse the whole data packet under certain circumstances? How could a prediction take care of that? Climate prediction, for example, will do more or less processing based on the year-by-year results it calculates within one work unit. If the predicted weather conditions are simple, the donor machine would fly through the calculations, if complex then much more processing time would be required. There's no way of knowing this beforehand.

Whichever way you look at it, there is no way to accurately preload a score per workunit, and so the current system has to stay. If the servers were dishing out work units in quantity, and taking results at the same rate, everyone would soon settle into a pattern where cobblestones granted would be a constant process, with the pending cobblestones sitting in a "buffer" between true result and work-in-progress. This buffer should reach a certain size and stabilise - I know my pending credit on predictor@home has displayed exactly this behaviour after a couple of weeks. When clients connect, my granted credit increments, I get more work, some results enter pending credit, some are removed into granted. The process is smooth and painless.

I think maybe we should give the whole credit system a fair trial once work units are in near constant supply - I anticipate most of the perceived issues would disappear.

> So you saying that if I fill my machine with Dry Ice, and O/c it to 4Ghz - run
> the benchmark, then set the computer back to normal. Every time I do a WU it
> will think my computer has been running at 4Ghz for the whole WU?

Well, this would be very nice but…………..
The system is working in such a way benchmark is running automatically in a fix interval of days.
If you like it or not that is another question.
This has been validated in order to keep the benchmark results in accordance to an eventually change of hardware inside each PC.

The way of calculation of credit is quite simple.
It takes into consideration 2 different things:
one is the CPU time
the other is the benchmark results.

That means very simply the following:
Slow PC's are compensated in credits against fast PC's because the slow ones have long CPU timings and low benchmark results, the up to date PC's have short CPU timings but high benchmark results.

It would have been a pity to put "old" computers in an unfavorable situation against up to date PC's.

By using this type of calculation, it does not matter if you have a powerful computer or not. Therefore, everybody should be happy.


Greetings from Belgium.