Yes, guess so. Have to offer extreme credit to get people interested in crunching for them. Math - Yuck!

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

BLC = Bloody Lousy Credit

---

BLC = Bloody Lousy Credit

Nah, it's purely due to Credit New.
Some of the highlights-

different projects should grant about the same amount of credit per host-hour, averaged over hosts. Projects with GPU apps should grant credit in proportion to the efficiency of the apps. (This means that projects with efficient GPU apps will grant more credit than projects with inefficient apps. That's OK).

What does it consider efficiency to be?

The efficiency of an application running on a given host is the ratio of actual FLOPS to peak FLOPS.

How does it determine peak FLOPS?

BOINC estimates the peak FLOPS of each processor. For CPUs, this is the Whetstone benchmark score. For GPUs, it's given by a manufacturer-supplied formula.
Notes:
•For our purposes, the peak FLOPS of a device is based on single or double precision, whichever is higher.
•BOINC's estimate of the peak FLOPS of a device may be wrong, e.g. because the manufacturer's formula is incomplete or wrong.

Actual FLOPs appear to be an estimate by the project.

Peak FLOP Count
•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.

So GPUs are penalized if they aren't "efficient". CPUs aren't.

Cross-version normalization
•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.

If the intent was for a WU to be granted Credit for the work done, not based on what did it then oh boy does it not work as intended!

Host normalization
The second normalization is across hosts. Assume jobs for a given app are distributed uniformly among hosts. Then the average credit per job should be the same for all hosts.

Anyone here that keeps an eye on their work will know that jobs are not distributed uniformly among hosts.

•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.

So CPUs get more Credit for the work they do, and GPUs get less. It has been designed that way.

Anonymous platform
Notes:
•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.

For those that reschedule

Cherry picking

Suppose an application has a mix of long and short jobs. If a client intentionally discards (or aborts, or reports errors from , or moves to a different processor) the long jobs, but completes the short jobs, its host scaling factor will become large, and it will get excessive credit for the short jobs. This is called "cherry picking".

The host punishment mechanism doesn't deal effectively with cherry picking,

The following mechanism deals with cherry picking:
•For each (host, app version) maintain "host_scale_time". This is the earliest time at which host scaling will be applied.
•for each (host, app version) maintain "scale_probation" (initially true).
•When send a job to a host, if scale_probation is true, set host_scale_time to now+X, where X is the app's delay bound.
•When a job is successfully validated, and now > host_scale_time, set scale_probation to false.
•If a job times out or errors out, set scale_probation to true, max the scale factor with 1, and set host_scale_time to now+X.
•when computing claimed credit for a job, and now < host_scale_time, don't use the host scale factor

The idea is to use the host scaling factor only if there's solid evidence that the host is NOT cherry picking.

Because this mechanism is punitive to hosts that experience actual failures, it's selectable on a per-application basis (default off).

In addition, to limit the extent of cheating (in case the above mechanism is defeated somehow) the host scaling factor will be min'd with a constant (say, 10).

Text in italics, my addition.
The default value for this feature is off- whether that is the case here at Seti or not, I've no idea.


As you can see it's based on a lot of estimates, which for one reason or another often aren't that close to reality.
And worse yet- it's idea of efficiency results in GPUs being penalized, even though by any normal measure of efficiency (Watt Hours per WU processed, number of WUs processed per hour etc) A mid-range GPU leaves a mid range CPU way behind, and the high-end GPUs leave everything else way behind.

---

Grant
Darwin NT

In addition to Grant's comments.
The basic philosophy of CreditNew is flawed, in that rather than being based on some measurable feature of the data being analysed it is based on the assumed performance and run-time achieved by those performing the analysis.
Additionally the process is very rarely "recalibrated" to ensure that it is actually "being fair" in its calculation of awarded credit. One thing to note is that for each valid work unit the credit is first calculated for both hosts, then the awarded credit is based on the lower value. Which is why rescheduling from CPU to GPU results in lower credit than one would get without such rescheduling - the calculation is based on the processor type (CPU/GPU) that the task was intended for, not that actually used.

---

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

So it's a lose or lose game.

If we reschedule we receive less credit, but if we not reschedule our host will run empty on each outage.

Who wins the game? Less credit or less WU? Make your bets.

---

Given all that, it could also be said, that if one can't afford the 'latest and greatest' of anything much, they are being penalised. The most efficient of this and that, have a very noticeable initial cost, although their running costs may be lower. It is the same reason that a person who doesn't have a fantastically well-paid job, is driving a ten-year-old car with a diesel engine as opposed to a shiny, new, Tesla! In the last three or four years, we've seen far more efficient PSUs, GPUs etc, etc, etc become available, but not everyone can afford them, especially when there are more important calls on finances. All this being so, one has to wonder if the premise behind the project has been quietly forgotten. Surely the work that done on a seven-year-old (or even older) GPU should be as 'valued' as the work done by the latest, most efficient Amidia GPU to date? If not, then there is clearly a playing field that is anything but flat and seemingly, financially discriminatory.

---

Don't take life too seriously, as you'll never come out of it alive!

Thus spake a true credit hound.
Perhaps it is a scheme to get rid of the credit hounds?

All my machines run out of tasks during the Tuesday outrage, which means other projects get a chance to run. All you are doing by rescheduling is assisting in the continued crash in the credits/task
.

---

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

Would someone please try to explain to me, in somewhat simple terms, why it seems to be so difficult to come up with a way to award a standard amount of credit for a standard WU? I did read the info presented by Grant, but it just seems to me that if enough information is known about each WU, (it's range, level of difficulty, or whatever goes into it) it should be able to be calculated a given amount of credit, regardless of what platform or device it is ran on.

If it takes 6 minutes on a GTX1080Ti or 6+ hours on a duo core processor, I guess I feel that really shouldn't matter, you are crunching something, and popping out a (presumably valid) result at the end. The fact that it took longer or shorter I don't believe should really come into play, because at the end of the day, we are all crunching for the same results, for the same WU, regardless of the hardware. Is this an incorrect presumption?

I understand from reading that there are apparently ways of cheating the system, I don't know enough about it to even attempt to speak on that issue, and the fact that it happens really sucks. Brings up that saying That's why we can't have nice things.. But, is that the main reason that CreditScrew is the mess that it is in, to attempt to eliminate as much as possible the ability to cheat the system? I know that this has been discussed for years, pretty much since it was introduced, and I suppose if it were either easy or a priority (not sure which, or maybe both) it would have been addressed by now.

I'm just trying to get my head around why it has to be the way it is, and why it can't seem to be properly fixed to assign consistent awards for same/very similar WU's. And not trying to stir the pot, but if someone could shed more light on this in a relatively easy to understand manner, I know many people would appreciate it. Or direct me to a previous post where it has been covered in that manner so I can wrap my head around it and understand the situation.

---

It isn't. But somebody decided to have an immensely complex credit system, which is poorly documented, and poorly implemented, which makes maintaining it a very hard task.

Even to "unpick" the CreditNew code from the rest of the BOINC source is a bit off a struggle because bits of it are buried in apparently unrelated locations.

---

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

In theory there are ways to "stop" those that "cheat the system", but there may be consequences that are very hard to predict....

---

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

And I guess we'd have to define 'cheating the system' as well. Is rescheduling tasks that were assigned to a CPU but would actually run much more efficiently on a GPU considered cheating? And if this is what is happening, why in the world would it even be assigned to a CPU in the first place, if it would be so much better to run said WU on the GPU? I understand that there is so much I don't know, but am trying to get a good grasp of the basics.

---

It isn't. But somebody decided to have an immensely complex credit system, which is poorly documented, and poorly implemented, which makes maintaining it a very hard task.

Even to "unpick" the CreditNew code from the rest of the BOINC source is a bit off a struggle because bits of it are buried in apparently unrelated locations.

It would require hiring a developer to either modify or remove the CreditNew algorithm from the BOINC code. Two choices. Modify the code to properly award credit consistently for the flops used to complete the task the same across all devices or simply assign a fixed amount of credit for task type. This is the method the Einstein project uses. I get 3465 credits for EVERY FGRPB1G task whether it takes 600 seconds on a 1070Ti or 1150 seconds on a 970.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

The reason for assigning tasks to (random) types of processor is to try to reduce the impact of a "busted" application screwing up the results. Given the high degree of optimisation even with the stock applications it wouldn't take much of hick in say a GPU driver to causse lots of folks to start spewing back "rubbish" results.

---

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

or simply assign a fixed amount of credit for task type. This is the method the Einstein project uses. I get 3465 credits for EVERY FGRPB1G task whether it takes 600 seconds on a 1070Ti or 1150 seconds on a 970.

Simple and fair, someone press DA to use it on SETI.

or simply assign a fixed amount of credit for task type. This is the method the Einstein project uses. I get 3465 credits for EVERY FGRPB1G task whether it takes 600 seconds on a 1070Ti or 1150 seconds on a 970.

Simple and fair, someone press DA to use it on SETI.

DA has very little to do with project lately. He isn't the one to directly approach about fixing the credit system. Better to direct an appeal to Richard Haselgrove who can present it to the BOINC Management Committee for action.

ProjectGovernance

PMC_Minutes_2017_12_15

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

Awarded credit is actually a project issue, not a "BOINC wide" issue. Very few projects actually use CreditScrew for various reasons, most appear to prefer a simple credit per task system rather than the "chicken bones and stairwell" that is CreditScrew.

---

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

Awarded credit is actually a project issue, not a "BOINC wide" issue. Very few projects actually use CreditScrew for various reasons, most appear to prefer a simple credit per task system rather than the "chicken bones and stairwell" that is CreditScrew.

This is true. What I meant in my previous post is to either fix how the CreditNew algorithm in BOINC works or remove the CreditNew algorithm from the SETI servers code and simply assign credit for a task type.

To give an example of the extreme lunacy of CreditNew I present 3 cpu work units completed at GPUGrid.net

16814899	12962662	456812	3 Jan 2018 | 23:35:06 UTC	3 Jan 2018 | 23:59:57 UTC	Completed and validated	1,004.25  3,726.36     164.20   Quantum Chemistry v3.14 (mt)

16815108	12962868	456812	3 Jan 2018 | 23:38:48 UTC	4 Jan 2018 | 1:37:30 UTC	Completed and validated	987.55	3,685.36	21.94	Quantum Chemistry v3.14 (mt)

16819557	12967258	456812	5 Jan 2018 | 2:10:17 UTC	5 Jan 2018 | 4:10:34 UTC	Completed and validated	601.33	2,164.18	8.37	Quantum Chemistry v3.14 (mt)

We questioned the project scientists about the huge variance in credit assigned for similar flops used and cpu_time and they responded they didn't understand how the BOINC CreditNew algorithm worked and simply were using the BOINC software as delivered to them. They said they had no control over credit awarded, it was up to the BOINC software to assign credit.

---

Seti@Home classic workunits:20,676 CPU time:74,226 hours

A proud member of the OFA (Old Farts Association)

It is project related.
Some projects don`t use Credit New if i`m not mistaken.

---

With each crime and every kindness we birth our future.

or simply assign a fixed amount of credit for task type. This is the method the Einstein project uses. I get 3465 credits for EVERY FGRPB1G task whether it takes 600 seconds on a 1070Ti or 1150 seconds on a 970.

Simple and fair, someone press DA to use it on SETI.

A flat credit rate MINUS the percentage of rubbish returned for the last 10,000 tasks ... you run errors, you get penalized ... encouragement to fix your system :)

lack of AP make me falling down ...

---