You said the card's theoretical maximum is being used and that's why the GPU pairs are scoring 159 to 173.

To that I respond:
The cards TBar is using have a theoretical maximum of at least 2000 GFLOPS, a conservative number which I'll use for simplicity.
Since CN ignores GPUs we have to pretend this card is a single core CPU.

In 24hrs 2000 GFLOPS multiplied by 200 Cobblestones is 400,000 credits per day.
Divide 400,000 by 86,400 seconds in a day and we get 4.63 (rounded) credits per second.
4.63 credits per second times an average of 380 seconds (per said tasks) my ego math says is:

1,759

Now please explain to me again how I'm "TOTALLY wrong".

You mention cobblestones. A cobblestone is a measure of work done. A cobblestone (cobblestones) per day would be the equivalent measure of speed.

The speed of the processing device is not taken into account in any honest discussion of credit. The work done in the course of a single task (of given AR) is a universal constant - neglecting accidents like overflow results arising from RFI.

The credit per task should be the same whether the work is done (over the course of several weeks) by an android phone, or in the blink of an eyelid by a quantum supercomputer.

The benefit of super hardware or optimised software turns up in measurement units which have a time component, like RAC: you just return more of the damn things per day, but each one has the same, fixed, value.

Since CN ignores GPUs we have to pretend this card is a single core CPU.
....
Now please explain to me again how I'm "TOTALLY wrong".

Credit New doesn't ignore GPUs, it just doesn't handle them well.

And if we're lucky, the current period of GBT only work will last for some time, and you can watch the amount of Credit being awarded start to fall.

---

Grant
Darwin NT

4.63 credits per second times an average of 380 seconds (per said tasks) my ego math says is:

1,759

Now please explain to me again how I'm "TOTALLY wrong".

If the rate derived from theoretical (marketing) speed ratings leads to a guesstimate of 4.63 credits per second, and an average of 380 seconds per task is normal, then my brain says that the application is less efficient / slower than the author would like it to be, in comparison with the advertised speed.

By the definition of a cobblestone, more fpops per task means more credit per task, right?

Yes and no.
It WILL but up to a point.
If Eric inputs a gazzillion fpops in there CreditNew will slap it down.

Handily my above post is a useful example.
That theoretical machine produces a MAXIMUM of 400,000 credits per day.
So assuming we had a task that ran exactly 24hrs on that machine and Eric wanted said task to score 1 Million...
CreditNew would slap it down to 400,000.

Eric loses :)

There are signs, from discussions like this, that there are proper professional mathematicians and engineers who might just be girding their loins to undertake a proper theroretical evaluation of the CreditNew algorithm (or should that be heuristic?) to work out once and for all whether it does what it says on the tin. We tried this about five years ago: not being a professional mathematician or engineer, I watched from the sidelines. I was disappointed that we didn't reach a publishable conclusion.

But we did gather some evidence along the way, most notably at Albert (Einstein@Home's Beta project). But I think I saw some evidence in the data that Credit New was most sensitive of all to <rsc_fpops_est> - the 'size of the task', as a dimensionless number of floating point operations in total for the task. Note that this number has no time dimension at all: it is completely independent of speed.

Working with Josh Von Korff in the final stages of Astropulse development (before launch - so again around 2009), I seem to remember arguing that <rsc_fpops_est> should be deliberately halved, because over time the value for MultiBeam tasks had drifted too high for the applications of the day (by using clever programming, they could perform two or three - or more - operations per benchmark cycle). This was leading to a 'normal' DCF of around 0.2: I was arguing that with the launch of AP, we should nudge this some of the way back towards 1.

It would be interesting to learn whether my suggestion has any impact on the relative credit rates of MB and AP to this day...

That makes your comment that 'Eric wanted said task...' possibly much closer to the kernel of the problem than even you realised. Eric sets <rsc_fpops_est>, and other Erics at other BOINC projects set some pretty crappy <rsc_fpops_est>s. That might account for at least some of the bad press that CN gets.

If Eric inputs a gazzillion fpops in there CreditNew will slap it down.

GPU yes, CPU no.

Remember, efficiency only matters for GPUs, it doesn't matter for CPUs. GPUs are penalized for perceived inefficiency. CPUs are not. Even though by any measure of actual performance a highend GPU is more efficient than a highend CPU (per core, per GPU and for stock applications. Extreme multi core CPUs can put out more work, although their per core efficiency is still much less than a GPU. Except where Petrie's optimized application is running & a highend GPU will outperform even multi socket/multicore CPU systems).

•We use elapsed time instead of actual device time (e.g., CPU time). If a job uses a resource inefficiently (e.g., a CPU job that does lots of disk I/O) PFC() won't reflect this. That's OK. The key thing is that BOINC allocated the device to the job, whether or not the job used it efficiently.

•Version normalization addresses the common situation where an app's GPU version is much less efficient than the CPU version (i.e. the ratio of actual FLOPs to peak FLOPs is much less). To a certain extent, this mechanism shifts the system towards the "Actual FLOPs" philosophy, since credit is granted based on the most efficient app version. It's not exactly "Actual FLOPs", since the most efficient version may not be 100% efficient.
•If jobs are not distributed uniformly among versions (e.g. if SETI@home VLAR jobs are done only by the CPU version) then this mechanism doesn't work as intended. One solution is to create separate apps for separate types of jobs.

•The host normalization mechanism reduces the claimed credit of hosts that are less efficient than average, and increases the claimed credit of hosts that are more efficient than average.

By design, Credit New penalises what it considers inefficient hardware. ie where the estimated peak work done (FLOPS) doesn't come close to the theoretical capability of the hardware ie GPUs. And it boosts the Credit awarded to what it considers to be more efficient hosts ie CPUs.


Almost forgot this bit

•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. This could be fixed by creating app_version records representing all anonymous platform apps of a given platform and resource type.

---

Grant
Darwin NT

And when a project has an application which runs exclusively on GPUs (like GPUGrid, and Einstein's "Gamma-ray pulsar binary search #1 on GPUs" and "Binary Radio Pulsar Search (Arecibo, GPU)" - there are no equivalents at SETI), CreditNew has no reference point for normalisation, and credit grows exponentially - we saw that at Albert, but pulled the plug before things got too explosive...

Hmmmm, I looked at this host iwazaru, and it appears it is being awarded More credit per GBT task than My machine. I'm getting quite a few GBT tasks scoring less than 60 credits whereas 8498942 doesn't appear to have a single one scoring less than 60. Has he found a way to trick CN into awarding more credit? Speaking of GBT tasks scoring less than 60 credits, all of mine have one constant, they seem to all involve CPUs. There are a few that score higher, but all the ones below 60 with my GPUs, are matched with CPUs. Look for yourself, look for tasks taking around 200 seconds and scoring less than 60 credits.

BTW, if host 8498942 were to Stop using that Intel iGPU his CPU times would be Much better and more that offset the loss of the Intel iGPU.

You are still totally WRONG because you are ignoring how the theory has been implemented on SETI@Home - there are scaling and capping factors built in which effectively scale credit by a factor of 0.1
As I said earlier, you may look at the definitions in BOINC's documentation, but every project can implement them or not as it chooses, and the outcome is correct for that project, and DO NOT attempt to compare credit granted (per hour) between projects because just about every project uses their own, which is "rather annoying", and somewhat defeats the one of the stated objectives of CreditNew which was to be more or less "the same reward for the same effort" across projects.

---

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

Thanks for digging that out Tbar - the reason for the inflated scores for 8498942 compared to yours is that the result of using the iGPU is to drag down the net processing power, so make it appear to be slower than it really should be. Also being a very new machine it hasn't had time for CreditScrew to "learn" how to "screw its scores down" properly - although today I see there are far more 60s and 70s than anything else - with one high score which is against a nVidia GPU - no surprise there as this was two GPUs validating against each other and being awarded higher scores than they would against a CPU.

---

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

TBar & rob

I'm gonna be creating a thread about this laptop soonishly so I guess you can scrutinize it there to your hearts' content :)

@TBar WTF dude, why are you being so pissy towards me? Did you think I was accusing you of cheating?

Probably because you refuse to read what has been said repeatedly - and I re-iterate it again - DO NOT MIX theory and the actual implementation, and DO NOT attempt to compare credit awarded between projects.

---

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

In theory - credit should be comparable between projects, because it has a theoretical underpinning in computing facts.

In practice - credit cannot be compared across projects, because project administrators have departed from computing science.

There are several reasons for this. My theories include:

A deliberate attempt to recruit additional volunteers to their project's scientific research
Undue weakness in responding to volunteer requests for additional credit in threads like this one
Political judgement in assessing that allowing credit creep to occur has additional project benefits elsewhere

Richard - thanks for that, something else for me to dig into. I think I can picture the bit of code, but I need to check it again to see if my memory is correct.
( = more bits of paper with trace lines drawn all over the place....)

---

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

I think I can beat that :))



Three weeks from a standing start, new app_version, GPU only. Note that I have split 'reporting time' from 'validation time' - so the red dots in the top left had much longer CreditNew settling time while waiting for wingmates. Zeroes along the bottom were probably still waiting for wingmates.

rob, either learn to read or leave me alone.

That's the second time you are going off on a tangent about other BOINC projects. I got the Bank of Zimbabwe speech 5 yrs ago from Richard. It had nothing to do with what I was saying back then and it has nothing to do with what I'm saying now. The other projects and their credit systems are non-existent to me.

If you want to vent your anger about other projects awarding phony credits you can create a thread about it.

And please stop pretending I ever said anything about other projects. I doubt I even said anything that that could be "twisted" into making it look like I was talking about other projects.

Understood. But the thread title is about CreditNew, and CN is designed to be used across the whole range of BOINC projects - some of us are interested in fixing that.

Fixing CreditSETI for SETI only has intellectual integrity. Fixing CreditNew for BOINC likewise.

But fixing CreditNew for SETI only doesn't work - there are cases, like the graph I've just posted, which SETI simply doesn't see, because we don't have applications like that.

With your current attitude I'm not surprised you got the Bank of Zimbabwe speech from Richard, because you refuse to read what is being said - (and remember since this is an "open" conversation others may read it, and, incorrectly, assume that all projects apply the credit system in a uniform manner, so some phrases may not directly apply to yourself, but to the "casual reader" of this thread.

---

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

Understood. But the thread title is about CreditNew, and CN is designed to be used across the whole range of BOINC projects - some of us are interested in fixing that.

Apologies Richard. Rob is on a holy war because I crossed out a word of his. He's gone nuclear over a strikeout and it's caught me off guard. I'm trying to mop up after his overreaction and in my haste there are probably a few things that could have been better written.

IOW I never meant to imply (if that's how it looks) that Boinc-wide credit should not be discussed. In fact I actually enjoy your posts on the subject. How do you think I already knew everything you were telling me 5 years ago? :) It was because of your posts.

What I was trying to say (to Rob only) is:

...DO NOT attempt to compare credit awarded between projects.

I wasn't and I didn't.