Eric Korpela Wrote

There seem to be a lot of misconceptions about the relationship between CreditNew and the decrease in credit granted for some people.

"Some people" ?? Sorry Dr K but that that sounds like a politician saying that "some people" were disadvantaged by the GFC. The info on stats sites says that the RAC of the entire project has suffered and the SAH site shows that the RAC of every computer in the top 1000 has dropped

First, we've been using CreditNew for far longer than S@H v7 has been around. CreditNew is not all that new.

Second, there are no knobs to turn to increase credit. That was kind of the point of CreditNew. It more accurate to say that all the knobs are still there, it's just that turning them is counteracted by the CreditNew mechanism. I know, I've tried to turn them all with no effect.

No problem with either of these statements, I do believe you have tried to fix this problem within the limitations of what's available to you.

Third, the credit decrease is by no means universal. For S@H v6, the elapsed time based credit for the stock cpu app on the average windows machine was scaled by 0.984311268359135. For S@H v7, the elapsed time based credit is scaled by 0.997756082254495. That's right, according to our server, windows machines are getting 1.3% more credit per second than they did under v6.

Is this a case of "Lies, damned lies and statistics" (to quote Samuel Clements) ?? As it is not showing out here in the real world.

Where might the difference people are seeing come from? Maybe GPU apps. The efficiency of GPU based apps is different on between v6 and v7. Some parts of the code are more efficient, especially if you've got a GPU optimized for CUDA5. But the balance between different portions of the code has been changed by autocorrelation. Since we grant credit based on actual work, your GPU might be getting more or less credits per second.

Could you (or some other knowledgeable person) please define what you mean by "work" ? If my GPU is running at 98% load and pulling 200W from the power supply it's certainly doing something that appears very much like "work".

And then there are optimized apps. We can't make any guarantees about the rate at which a non-stock app gets credit. Since credits are referenced to the stock apps.....

When V7 was first released, I ran the stock CPU and GPU apps on my machine number 4414279 for a month. This was so I could get a baseline so I could see how much the optimised apps improved things. Despite running the standard apps, the RAC of this machine still fell like a stone to the ~58% of V6 which seems to be about the same drop everyone else is suffering.

....For many projects there seems to be no relationship between credit granted and work done

And now SAH has joined them, only it has gone the other way :)

CUDA5 GPUs are about 2.5% efficient when running SETI@home

Could you please explain how you define "efficiency" here ? In my game, efficiency is calculated by dividing output power by input power and converting the result to a percentage. Because I am a simple person, please explain what this "2.5%" actually means.

If we assumed GPUs were 100% efficient, and had a GPU-only app we could boost your credit rate by 40X.

Nobody here wants the credit rate increased by 40X. It's just that we don't want it decreased by such a significant factor either.

I would also be grateful to anyone who can explain the actual reason why V7 units score lower than V6 or AP. What is "inside" them that causes the credit system to rate a unit, that is obviously requires more crunching (i.e. they take twice as long to complete on both CPU and GPU, and use more flops) much lower than their predecessors across all AR's ?

Before I get jumped on by "The Defenders of the Faith", let me explain that I am not a "credit hound". I am just a person who like building "hot" computers and my SAH RAC was a convenient "dynomometer" for judging their performance and comparing them against similar machines. I'm not even blaming "Credit New", I would just like an explanation of why this has happened.

But I prefer that they (credits) mean something.

Isn't that the point of this entire thread ?

T.A.

Because I am a simple person, please explain what this "2.5%" actually means.

It means you are wasting 97.5% of your electricity:) No joke.
In other words you would get 40x the credit/work-done if running at 100% efficiency. And yes, you'd still be pulling the same 200W.

Because I am a simple person, please explain what this "2.5%" actually means.

It means you are wasting 97.5% of your electricity:) No joke.
In other words you would get 40x the credit/work-done if running at 100% efficiency. And yes, you'd still be pulling the same 200W.

Thanks Alex, but why ? That figure makes modern electronics less efficient than an 18th century steam engine.

I fully understand about resistance losses in a device etc. But what is actually happening "inside" ? From the GPU temperatures it doesn't seem to be dissipating 195W as heat. Where is the rest of the energy going ?

T.A.

CUDA5 GPUs are about 2.5% efficient when running SETI@home

Could you please explain how you define "efficiency" here ? In my game, efficiency is calculated by dividing output power by input power and converting the result to a percentage. Because I am a simple person, please explain what this "2.5%" actually means.

For my 2 cents, that's approximate actual flops minus communication cost over marketing flops, i.e. limit (0.5x-1)/inf, as x approaches zero.

Let's make this a little bit clearer:

Apollo

29 21/08/2013 1:38:30 PM NVIDIA GPU 0: GeForce GTX 780 (driver version 32641, CUDA version 5050, compute capability 3.5, 3072MB, 4698 GFLOPS peak)

Who's claiming this? Show me the code that achieves this. You can't seriously be basing efficiency calculations on this can you ? A 384-bit GDDR5 memory bus does not go this fast. [Hint: the theoretical bandwidth on this card is shown in nVidia control panel as 288.38 GB/s,a floating point operation requires 2 operands of size float, each float is 4 bytes.]

Let's see what the efficiency calculations are based on.

Note that unfortunately I've yet to receive any response from Eric or the Linux & Mac Developer community to my request for input into getting public beta happening for x41zc, nor to earlier enquiries supporting my research into GPU reliability, aimed at improving fault tolerance.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.

I hate telling you you are wrong but what can I say? It's math:) This one I can actually show you with equations but I'm not sure I can get it done tonight. Gimme some time and I'll do a separate thread on it.

Flop counting was dropped with transition to CreditNew. Only if "stock" app would be locked forever, w/o any change, ONLY then credits would be proportional to FLOPS in task. At each stock app change coefficient in proportion is changed. Hence, it's not flop-counter. Regarding FLOPS measurement it's like to measure length with plastic meter. And cut this meter time to time.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Apollo

29 21/08/2013 1:38:30 PM NVIDIA GPU 0: GeForce GTX 780 (driver version 32641, CUDA version 5050, compute capability 3.5, 3072MB, 4698 GFLOPS peak)

Who's claiming this? Show me the code that achieves this.

Yes, that number is based on a lot of bad assumptions yet many GPU only projects or apps use it for calculating credit... It assumes 1) that there is no GPU memory latency. 2) The GPU is capable of performing every operation in one cycle. 3) Every operation necessary for the program can be parallelized to the maximum capability of the GPU and 4) the GPU doesn't stall while data is being transferred over the bus from CPU memory to GPU memory. All of those assumptions are wrong. In reality the machine above is running at 245 bGFLOP (benchmark-GFLOP which is the unit the BOINC client measures) 5.2% of "peak" which is about 86 real GFLOP/s. That's really 1.8% of "peak".

When talking about efficiency, I was talking about the former number which is based on the average windows machine doing 1 real FLOP for every 2.85 benchmark FLOP. So when I said 2.5% effificient, I really meant 0.88% efficient.

You can't seriously be basing efficiency calculations on this can you ?

Perhaps efficiency is a bad term. What I'm talking about is the ratio between what the BOINC client thinks the GPU is capable of doing, and the real world capabilities. If you've got a better way of calculating performance that can go into the BOINC client, I would push for that. Frankly, I would like to go back to FLOP counting, but none of the other projects were willing to spend the day of programming that it would take to add it to their apps. And all support for it has been removed from BOINC entirely.

Note that unfortunately I've yet to receive any response from Eric or the Linux & Mac Developer community to my request for input into getting public beta happening for x41zc, nor to earlier enquiries supporting my research into GPU reliability, aimed at improving fault tolerance.

Sorry about that, the email I assume you are talking about is still in my unread pile.

---

@SETIEric@qoto.org (Mastodon)

Thanks for taking time out Eric to answer these queries. Much appreciated.

---

+1

TY

---

...

Flop counting was dropped with transition to CreditNew. Only if "stock" app would be locked forever, w/o any change, ONLY then credits would be proportional to FLOPS in task. At each stock app change coefficient in proportion is changed. Hence, it's not flop-counter. Regarding FLOPS measurement it's like to measure length with plastic meter. And cut this meter time to time.

I think where we disagree is the severity. I know what you are saying is technically correct, I'm just not sure the plastic stick has been chopped off enough to make any real impact. Maybe I'm incurably optimistic but that's why I think the word 'credit' there on the left side of the screen is still interchangeable with 'cobblestone'. And of course Cobblestones are translatable to GFLOPS and GFLOPs.

We know CreditNew is pretty much SETI only, so what other projects are doing with their 'credits' is irrelevant. We also know Seti to be fair with credits and play by the rules. When CN was introduced during V6 (well, probably a few months after it was introduced) RAC was not that far off AFAIK to Eric's far more elegant and accurate actual FLOPs counting. Probably because there was a ton of data for CN to work towards and 'emulate'.

Now I know we're on V7 and it's all guesswork but the numbers between stock V6 and V7 CPU seem consistent and therefor, after going through a few hoops and loops, still essentially a flopcounter (in my mind). Unless there is something I'm missing? I have no doubt there may exist some piece of information I'm unaware of that would prove me way off base:)

In fact, shockingly, like Eric has already mentioned I think the new stock apps are cheating marginally and claiming more FLOPs:) I've seen this behavior on my obviously non-AVX ATOM. But again, well within my own personal comfort-zone for margin-of-error to still be calling credits a flopcounter.

So again, though maybe a 'crude' flopcounter... still a flopcounter. But I'm assuming it's off by 'only' 10-15%. If you can show me it's more than that I'll be happy to never ever call credits 'FLOPs' again:)

But that wasn't even the point. The point is for months I thought it got broken but it turns out it was not! Or like you like to say, "working as designed, just not designed well" :)

PS JG & Eric, Thanx for the replies. We love to learn!

There is a simple way to fix all the problems. Split the project, create a separate RAC for MB & AP then nobody will claim about the credit diferences, you choice what you want to crunch and have a fair comparision on the work done.

---

A funny thing happened when I read, to the best of my ability, the CN wiki page. This:

In the current design, anonymous platform jobs don't contributed to
app.min_avg_pfc, but it may be used to determine their credit. This may cause
problems: e.g., suppose a project offers an inefficient version and volunteers 
make a much more efficient version and run it anonymous platform. They'd get an
unfairly low amount of credit.

Because the anon results are not used to calculate the global average of how fast the "reference" app is, usually the cpu app if there is one. So if you are running an improved anon cpu app, faster run times -> lower pfc -> interpreted as smaller jobs and not faster run times -> less credit.

Really, CN should treat the anonymous platform apps as different versions but it doesn't, at least not according to the wiki page which appears to be a little old.

I don't *think* that's related to the present kerfuffle, but interesting.

I don't think that paragraph applies very often. Once a host has done 10 non-outlier results with an anonymous platform app version, it gets it's own host scale factor based on its own PFC. In the credit granting code, anonymous platform credit calculations are always considered to be approximate, so it's weighted less heavily (50%, IIRC) than the stock applications in the credit calculation.

Credit calcs are more complicated in CreditNew. There are the NORMAL and APPROX weightings, and there is also a weighting by how close to the app's average credit you are. That weight is there to prevent some of the exceptionally low credit situations we had in the past when we would always pick the lower one. Now we pick an average that is weighted toward the one that is closest to the long term average.


I just read that paragraph again. It's only true in the case where a project uses single redundancy.

---

@SETIEric@qoto.org (Mastodon)

A question: why do the stock apps normalize two ways, across app versions and across hosts, while the anonymous platform only does the latter?

Primarily because we have no way of figuring out which specific binary is being run under anonymous platform, so we have to treat every anonymous version on a specific host as being the same. But in the end it doesn't really matter, because it ends up being exactly the same thing.

I have no idea why it's done this way, but for anonymous...

pfc = raw_pfc * (app.min_avg_pfc / host_app_version.pfc_avg);

And for stock...

pfc = raw_pfc * (app.min_avg_pfc / app_version.pfc_avg) * (app_version.pfc_avg / host_app_version.pfc_avg);

The real code is more complicated than that, but that's the essence. Then the granted credit is a weighted average of the pfcs where stock typically gets twice the weight of anonymous.

---

@SETIEric@qoto.org (Mastodon)

In the second equation, the app_version.pfc_avg's cancel out and you end up with the first equation. I too don't understand why the stock version doesn't use the anonymous method.

Could it be that, when you look at the details, the stock method reduces the variability in the result? Maybe it's just one of those things...

Now I know we're on V7 and it's all guesswork but the numbers between stock V6 and V7 CPU seem consistent and therefor, after going through a few hoops and loops, still essentially a flopcounter (in my mind). Unless there is something I'm missing?

I think you miss that CreditNew bound to some averaging of stock app. So, really it can't show anything else than "almost the same" for stock, no matter how stock itself changes.
I my analogue no matter how large or small plastic meter is it's ALWAYS 1m, by DEFINITION. All other world sizes will change, but not that plastic meter...

Just as we see with CreditNew. Third party apps "credits" are changed, stock credits remains the same. Unfortunately, this effect on V6->V7 transition is masked via third party app change too. Well, I hope to return to ICC in some future then it will be more clear.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

There is a simple way to fix all the problems. Split the project, create a separate RAC for MB & AP then nobody will claim about the credit diferences, you choice what you want to crunch and have a fair comparision on the work done.

And this would be final failure of CreditNew. Cause that main it's advertised advantage was INTERPROJECT comparability. And SETI MB vs SETI AP will be uncomparable just as AP and MB uncomparable right now.

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

A funny thing happened when I read, to the best of my ability, the CN wiki page. This:

In the current design, anonymous platform jobs don't contributed to
app.min_avg_pfc, but it may be used to determine their credit. This may cause
problems: e.g., suppose a project offers an inefficient version and volunteers 
make a much more efficient version and run it anonymous platform. They'd get an
unfairly low amount of credit.

Because the anon results are not used to calculate the global average of how fast the "reference" app is, usually the cpu app if there is one. So if you are running an improved anon cpu app, faster run times -> lower pfc -> interpreted as smaller jobs and not faster run times -> less credit.

Really, CN should treat the anonymous platform apps as different versions but it doesn't, at least not according to the wiki page which appears to be a little old.

I don't *think* that's related to the present kerfuffle, but interesting.

LoL, for me it looks like WiKi page says the same thing I trying to say all the time, just in other words. CreditNew PUNISHES optimization!

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Every credit method we've ever used, with the exception of FLOP counting punished optimization, especially optimization of the stock apps.

---

@SETIEric@qoto.org (Mastodon)

Every credit method we've ever used, with the exception of FLOP counting punished optimization, especially optimization of the stock apps.

Splendid design all of them, then :D

That was sarcasm. A design that punishes optimisation, credit wise, needs either that smiley who hits himself on the head with a hammer or the smiley that hits the other one with a pie.

---

A person who won't read has no advantage over one who can't read. (Mark Twain)