Credit New isn't a FLOPs counter.

Of course it is.
Just not real-time flops, or flops on a "per-task" basis.
It uses Recent Average... Cobblestones.
And that means it very much qualifies as a flopscounter.

Credit New isn't a FLOPs counter.

Of course it is.
Just not real-time flops, or flops on a "per-task" basis.
It uses Recent Average... Cobblestones.
And that means it very much qualifies as a flopscounter.

FLOPs counting here implies that a count is made of operations as they are performed, and a total kept. And that total is used to claim Credit.
That only occurred for the second Credit system.

The first and current system use the estimated number of operations required to process a WU (estimated FLOPs), the time taken to process it, and the estimated/benchmark FLOPs capability of the hardware that processed it. There is no counting of FLOPs done.

EDIT-
Yes, if the Credit system worked as it should, and you knew the efficiency of your hardware, then you could determine the number of FLOPs your system is doing using GigaFLOPs = RAC/200.
But as I posted previously, current RAC doesn't even come close to giving the correct value for FLOPs as current RAC for Seti systems is well less than half of what it should be if it were aligned with the definition of a Cobblestone.

And that FLOPS value would be a derived number, not a directly counted one. It's all comes back to the original estimated FLOPs for the given task (WU) being processed.

---

Grant
Darwin NT

There is no counting of FLOPs done.

Of course there is.
We may not like the fact it uses a wall-clock and a benchmark to do it, but it is what it is.

FLOPs counting here implies that a count is made of operations as they are performed, and a total kept

Let me take you on a cheesy trip down memory lane (and let me know if it makes you feel as old as I felt):
Go to the top of the page and click on the "Computing" drop-down menu, click on "Certificate" and then choose "View Diploma Certificate"

Tell me if you see "a total kept"
:)

Credit New isn't a FLOPs counter.

Of course it is.
Just not real-time flops, or flops on a "per-task" basis.
It uses Recent Average... Cobblestones.
And that means it very much qualifies as a flopscounter.

No its not, its a random number generator that slowly generates everything downwards. ;-)

Cheers.

Tell me if you see "a total kept":)

Yep, and the number of FLOPS there are incorrect, because the actual FLOPs aren't counted, they are derived, based on the Credit New system that is broken & doesn't pay out what it should based on the original definition of the Cobblestone.

It would be nice if each project were to develop an application to determine (count) the actual number of FLOPS each of their different WUs would require to be processed without any form of optimisation or shortcuts. But I doubt that's what Seti did, and I doubt if any other project has done it either.
So the FLOPs required to process a WU are an estimate. And the clients don't count the FLOPs done to process the work either.
So there is no FLOPs counting in the present system of the work done.
And the definition of the Cobblestone doesn't actually count FLOPs, it just says 1GFLOP=200/86,400 (1 day in seconds), hence the cobblestone_scale used for determining credit (200/86400e9) using the estimated (not counted) FLOPs for the job (WU).

---

Grant
Darwin NT

Apologies Grant, was multitasking with my reply open and never saw your edit, which made my reply a bit redundant. But anyway...

But as I posted previously, current RAC doesn't even come close to giving the correct value for FLOPs as current RAC for Seti systems is well less than half of what it should be if it were aligned with the definition of a Cobblestone.

Wiggo agrees :) And I get why everyone feels that way. I really do.

But let's test that statement of yours. You did all the math right when figuring out your system's total gflops but got blindsighted by the GPU performance. Now humor me for a minute and let's pretend that all GPU credits can be derived by CPU credits as long as the CPU derived credits are fairly accurate (don't overthink this, just trust me for now).

Pretend your system (either one) has no GPUs. What is your processor efficiency?

What is your processor efficiency?

Not a clue, anywhere from 40-75%. Given i'm running the AVX application, which gives around a 30% improvement in running times over the previous SSSE application I was using, and it was about 10- 15% better than the stock application at the time (I think, it was an eternity ago). So it would probably be around 40% better than the stock application of the time. How efficient was it?
Lets take a completely uniformed wild arse guess and say 25%.
So i'm probably up around 65-70% (this all depends on when the various applications came out in relation to when the various versions of Seti were released. Buggered if I can remember what version of Seti I was running when I moved from one optimised version to another, so these values have probably got an error range of +/- 50%).

---

Grant
Darwin NT

I didn't mean guess! I meant calculate :)
Multiply your whetstone benchmark by the number of cores you have running.
Then pick your highest APR from the CPU apps (or app if it's just one).
First number is your theoretical peak flops.
APR is (close enough) to your actual flops.

How efficient are your two procs?

I didn't mean guess! I meant calculate :)

This is why I suggested someone else workout what the amount of Credit per WU AR should be...

System 1
Whetstone 3.7 GFLOPS with 6 cores doing CPU work.
APR 33.7 GFLOPS

System 2
Whetstone 4.93 GFLOPS with 9 cores doing CPU work.
APR 59.52 GFLOPS

22.2 estimated v 33.7 actual = 151.8%
44.37 estimated v 59.52 actual= 134%
Which makes the amount of Credit we're getting for a WU even more ridiculous.

---

Grant
Darwin NT

As designed CreditNew is meant to be a scaled FLOPs count
But as implemented it is a very poor estimate, So poor indeed that it is a pseudo random number scaled by a poor estimate of FLOPs, and that poor estimate varies with time, the processor used, the application used and several other factors.
FLOPs counting over the range of processors available today, and the programming techniques does not return an accurate result, only a wild estimate, Raistmer has outlined a few of the reasons, as have several others including myself.

Too many people are passing comment based on a document several years old, and that document was essentially a design guide listing the project objectives. There has been no review of project performance to confirm that those objectives have been met. Or at least not one other than those informally performed by the users, particularly SETI users). Based on the evidence coming from the users (in the form of scores for tasks) CreditNew does not meet the objectives of being processor independent or application independent.

So, don't get hung up on what you think CreditNew is doing, accept that it is deeply flawed and does not actually count the number Floating Point Operations taken to do a task, it only guesses at them, and guesses badly.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

22.2 estimated v 33.7 actual = 151.8%
44.37 estimated v 59.52 actual= 134%
Which makes the amount of Credit we're getting for a WU even more ridiculous.

Congratulations, we just opened Pandora's box :)
We all keep assuming that re-implementing Eric's flop-based system would drive credit upwards.
If those numbers are anywhere near real (I think they are but can't know for sure) then...

We all keep assuming that re-implementing Eric's flop-based system would drive credit upwards.

So you agree Credit New is borked then? It results in Credit being awarded that is not what it should be, even if the amount of processing done is directly counted?
That in addition to the variable amount of Credit awarded to a given being dependent on the hardware, software, OS, drivers & wingman involved.

As I keep pointing out; Credit should be paid in accordance with the original definition of the Cobblestone, which would result in the amount of Credit per WU being paid increase back to the level it should be, since the current levels of payment are well below that reference (let alone their variability).

---

Grant
Darwin NT

since the current levels of payment are well below that reference

Grant, your procs are not supposed to be more than 100% efficient :)

since the current levels of payment are well below that reference

Grant, your procs are not supposed to be more than 100% efficient :)

*shrug*

We can be like the early Astronomers, with the Earth at the centre of everything & continually have to re-adjust our models to make them fit the observed reality. Or we can be like Galileo, and change our reference to one that supports the observed reality and doesn't require endlessly revised & altered models to try and explain what is actually being observed.
Go back to basing the payment for work done on the Cobblestone as originally defined. No need for cross version normalisation, host normalisation, efficiency penalties; no need for further tweaks & scaling and other requirements so anonymous platform can be used without penalty; no need for yet more tweaks and scaling required to compensate for the fact the Seti WUs are not one single computation size. No need for all sorts of God knows what manipulations to make cross project comparisons possible, and relevant.

Go back to the original premise, with some scaling to account for the effect of different ARs, and everything else just falls in to place.
Problem solved.

---

Grant
Darwin NT

I didn't mean guess! I meant calculate :)
Multiply your whetstone benchmark by the number of cores you have running.
Then pick your highest APR from the CPU apps (or app if it's just one).
First number is your theoretical peak flops.
APR is (close enough) to your actual flops.

How efficient are your two procs?

OK, let's work it through for this computer (8498733):
Declared FLOPs = 2.44
4 threads active = 9.76

Version 8 = 14.38 (147%)
Version 8.05 = 21.12 (216%)
Version 8.08 = 24.24 (248%)

The three applications are "stock", and all pop up on the list used when I look back over the last few months.

Exit stage left your theory - the figure you are calculating is NOT processor efficiency, just, yet another, stupid figure that people use to have bragging rights about their processor.
As I've said previously, there are a number of definitions of "efficiency" in use within the calculations, and most of them do not help in this discussion of the credit giving process.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

We all keep assuming that re-implementing Eric's flop-based system would drive credit upwards.

Hmm, what are you saying? - That by re-coding a system that is inherently flawed will improve it?
Well for one, it isn't "Eric's" system, it is "David's".
Well, yes, change the scaling factors and you will increase the amount of credit per task.
There are two parts to any credit granting scheme - a "measured" part (we call it "FLOPs" in SETI and BOINC) and a scaling factor to get to a human understandable number. The scaling factor is very easy to alter - you want double the credit, then double the scaling factor. But changes in the measuring system are far from simple, as Raistmer has explained already, he had to work through his application (which was functioning and producing "good" results to find out where to put the triggers for the measurements.
But, that does not address the underlying issue - inconsistency in the eyes of the user - a given task should always get the same credit no matter what processor+application it is run on. The current system fails this very simple test, as you yourself have identified, it does not do that.

---

Bob Smith
Member of Seti PIPPS (Pluto is a Planet Protest Society)
Somewhere in the (un)known Universe?

OK, let's work it through for this computer (8498733):
Declared FLOPs = 2.44
4 threads active = 9.76

Version 8 = 14.38 (147%)
Version 8.05 = 21.12 (216%)
Version 8.08 = 24.24 (248%)

The three applications are "stock", and all pop up on the list used when I look back over the last few months.

That takes us back to the naughties - 2008 and before, when neither CN nor GPUs were in use. Runtime estimates were corrected via DCF, and that typically settled at around 0.2 for SETI tasks running on modern processors like the Core2 range. The basic reason is that <rsc_fpops_est> is overstated for MB tasks by - oooh, 248%? Probably 'again' rather than 'still', because there have been so many changes since then.

We all keep assuming that re-implementing Eric's flop-based system would drive credit upwards.

Hmm, what are you saying? - That by re-coding a system that is inherently flawed will improve it?
Well for one, it isn't "Eric's" system, it is "David's".

Inserting Eric's flop-counts into David's system makes my head hurt, but I don't think it'll work.

Using a modernised version of Eric's flop-counts and removing David's frilly bits round the edges is (a) technically hard work for an outcome which isn't top priority, and (b) politically very tense.

Just to add fuel to the fire, another advantage of moving to the system i've been advocating (based on the Cobblestone definition for those that have skipped many of the previous posts) is the fact that it is device independent.
Because the hardware, software, OS, drivers & wingman involved play no part in determining the Credit, and there is no need for cross device and version normalisation, and all the other stuff Credit New does means that rescheduling work becomes feasible, with no impact on Credit granted.

Not only that, it becomes something that could be implemented in the BOINC manager itself. For those that feel the need (i would certainly make use of an automatic BOINC Manager based rescheduler), web (or host) based settings would allow them to specify their preferred device for particular WUs. VLARs to the CPU, Ok. VHARs and AP to the GPU Ok. Don't care about any others, no problem.

Now when BOINC requests work to fill it's cache (within the serverside limits and project resources sharing set by the user) the Manager will request so much CPU & GPU work to meet the present shortfall, as it does now. The work is allocated by the Scheduler to the system. When the system receives the work as allocated by the Scheduler the BOINC Manager then re-allocates the work according to the users set preferences. If a bunch of VHARs comes down, and there is a shortfall in the GPU cache, it moves it to the GPU if was allocated to the CPU. Any VLAR work allocated to the GPU gets moved to the CPU queue, if there is room.
If there is a shortfall in either of the queues (within the serverside limits) then the Manager will request more work, and whatever is downloaded will remain allocated to that Device. When the queues become low, if necessary the work can be re-allocated & then more work requested. If it's ok then no re-allocation is required & more work is requested as required.
When the Manager re-allocates work, it re-calculates runtimes so the cache settings are still honored even if they are less than the serverside limits. And the next request for work will reflect that change in CPU/GPU/(external Quantum device) cache level.
WU runtime estimates are still correct, so Cache settings are still met (within serverside limits) and estimated time to completion in the Manager will be as accurate as it is today. Credit is still granted without variation because of the hardware, software, drivers, OS or wingman involved.

---

Grant
Darwin NT

the figure you are calculating is NOT processor efficiency

To the best of my abilities, I'm pretty sure it is.
But I can't be 100% sure which is why I keep saying I wish Joe were still around.

4 years ago:
"The current credit system is based on FLOPs"
http://boinc.berkeley.edu/trac/wiki/CreditGeneralized

6 years ago:
"BOINC estimates the peak FLOPS of each processor. For CPUs, this is the Whetstone benchmark score."
(bold NOT mine. It's in the original)
https://boinc.berkeley.edu/trac/wiki/CreditNew

What I don't understand is that the use of the word "peak" means/implies an app can't go above 100%.
Yet for all of CN's hoops, loops, "frills", and threats... here we are.