NorthCup, whatever you do, don't let out the Magic Smoke! That is what all computers run on, you know? ;-)

---

How does one do Beta tasks?...:-)

Attach to the project via http://setiweb.ssl.berkeley.edu/beta/

Thank you.

On the recent 'diet' of work, I've noticed a few things on my 'daily', running the Lunatics applications:-

CPU MBV8 APR......+40% roughly.

GPU MBV8 APR..... +10% roughly.

As for the RAC (accounting for my own new 'constraints'),..... -15% and possibly more to come.

This all seems somewhat contradictory. Is 'Credit Screw' really as much as I'm beginning to think it is?

---

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

On the recent 'diet' of work, I've noticed a few things on my 'daily', running the Lunatics applications:-

CPU MBV8 APR......+40% roughly.

GPU MBV8 APR..... +10% roughly.

As for the RAC (accounting for my own new 'constraints'),..... -15% and possibly more to come.

This all seems somewhat contradictory. Is 'Credit Screw' really as much as I'm beginning to think it is?

YES

---

SETI@home classic workunits 4,019
SETI@home classic CPU time 34,348 hours

This example of credit granted for a normal WU definitely looks off:
2819745779
Only 26 credits for 360s of GPU work or 3,935s of CPU work from the wingman seems well beyond a credit new effect. Perhaps there is a problem somewhere?

---

GitHub: Ricks-Lab
Instagram: ricks_labs

This example of credit granted for a normal WU definitely looks off:
2819745779
Only 26 credits for 360s of GPU work or 3,935s of CPU work from the wingman seems well beyond a credit new effect. Perhaps there is a problem somewhere?

If you go through your results, you'll see quite a few like that.
It's all to do with Credit New & the way it determines Credit.

My WAG (Wild Arse Guess)- your GPU APR (Average Processing Rate) is only 183.57 GFLOPS, I suspect the theoretical value for the GPU is much, much higher (checkout the first few startup lines in the log to see what the claimed FLOPS for that particular card is)- For that WU your Device peak FLOPS is 8,192.00 GFLOPS.
Yet your actual processing time is very quick, much faster than your APR would indicate.
Credit New considers your cards to be extremely inefficient (big discrepancy between APR & benchmark FLOPS) and a very high device Peak flops (with such a low APR means it's really, really in efficient, or the numbers have been fudged (it's interpretation)).
Credit New makes all sorts of assumptions, and if your figures don't meet those assumptions then it considers your figures to be a result of poor efficiency, or cheating, or both.
Final end result- bugger all credit for work done. By design.

---

Grant
Darwin NT

To underline what Grant has just said
CreditScrew copes GPUs very badly, and even worse when running multiple tasks per GPU. When conceived there was barely any concept of using GPUs to do the sort of computation we do, and even less of a GPU running multiple concurrent tasks. Thus the whole GPU side of the CreditScrew processing chain is "very poor" (other descriptors may be used).

---

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

Or another example of being penalized. AP work unit 2800471166 where I got a whopping 26 credits for a non-overflow, non-high blanked task simply because my wingman was the canonical result and took 2 1/2 days to crunch the task while my gpu did it in 12 minutes.

---

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

A proud member of the OFA (Old Farts Association)

Or another example of being penalized. AP work unit 2800471166 where I got a whopping 26 credits for a non-overflow, non-high blanked task simply because my wingman was the canonical result and took 2 1/2 days to crunch the task while my gpu did it in 12 minutes.

Run time 2 days 12 hours 17 min 16 sec
CPU time 1 days 13 hours 31 min 14 sec
That is one overloaded system!

---

Grant
Darwin NT

My RAC is still going up after the server issues in December.

. . There's always one :)

Stephen

:)

If you go through your results, you'll see quite a few like that.
It's all to do with Credit New & the way it determines Credit.

My WAG (Wild Arse Guess)- your GPU APR (Average Processing Rate) is only 183.57 GFLOPS, I suspect the theoretical value for the GPU is much, much higher (checkout the first few startup lines in the log to see what the claimed FLOPS for that particular card is)- For that WU your Device peak FLOPS is 8,192.00 GFLOPS.
Yet your actual processing time is very quick, much faster than your APR would indicate.
Credit New considers your cards to be extremely inefficient (big discrepancy between APR & benchmark FLOPS) and a very high device Peak flops (with such a low APR means it's really, really in efficient, or the numbers have been fudged (it's interpretation)).
Credit New makes all sorts of assumptions, and if your figures don't meet those assumptions then it considers your figures to be a result of poor efficiency, or cheating, or both.
Final end result- bugger all credit for work done. By design.

I watch my machines quite closely and have not noticed sub 50s credit awards like this in the past. I did try something different in the latest work shortage. I decide to try the rescheduler for the first time. I used it to move several hundred GPU tasks to CPU. Since I knew the machine would completely run out of work, I decided on a strategy to keep it fully loaded. I moved enough GPU tasks to CPU to make sure the CPU would be fully loaded while I slept my Sunday evening. I then enabled mining on the GPUs. In the morning, I stopped mining and un-suspended GPUs. Everything looked normal. Only thing that doesn't make sense is that it is not the rescheduled work that is getting the lower credit. It is the work that actually ran afterward on the GPUs. Anyone think this is the cause?

---

GitHub: Ricks-Lab
Instagram: ricks_labs

My RAC

. . My drop is much much steeper than that :(

Stephen

:(

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.

. . Comparing credit awarded to some older machines against that awarded to newer "more efficient" units, (in time and power) the older units seem to get higher credit while the newer units averagemuch lower credit/WU.

Stephen

? ?

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
.

. . It may indeed be a scheme to discourage those interested in achieving high credit. But intentional or not I suspect it will have just that effect to some degree. I cannot speak for all others but for myself re-scheduling is about improving the overall efficiency of my units and from discussions I know that is also true for many others that do it. Ironically, when using rescheduling the awarded credits were higher and more consistent than now that I am not doing it (apart from bunkering or the outrages). And that bunkering is not about actually running the task on another device but merely storing it there until the outrage begins and them moving it back to the original device for processing, thus have none of the effect you are concerned about. Again not about credit, just about keeping the machines doing what they were intended for, processing data for SETI.

Stephen

:)

But I guess my question is the base of the issue of credit hounding. My opinion stated previously is that if the credit system could be fixed to use a constant to give X credit for X work, regardless where it was ran, then the issue would evaporate. And rescheduling would be a thing of the past as well I would hope, because the software would be smart enough to know the best place to run any given unit, be it CPU or GPU.

I know we're a bit of a ways from achieving that, but hopefully it is in someones long term plan/goal for the software development for the project.

---

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?

. . What I understand CreditScrews purpose to be is to quantify productivity by assigning a credit value to work done, partly, and as a minor function, to provide feedback to the host owner/operator, but mainly to inform the schedulers for work assignment. Like yourself, this means to me is should be for the WU on the basis of work performed not by whichever device it was processed. Since APR is by definition the average processing actually performed by a device over time then the nett work performed in processing any given WU must simply be the APR multiplied by the time taken. The only definition I can find for a cobblestone (the alleged unit which is the basis for assigned credit) is the work performed in one day by a device with an APR of 1000 GFlops represents 100 cobblestones. If you actually look at these numbers for the work your rigs are performing it will become very clear that this is no longer the basis of assigned credit. As an example, on the GPUs in one of my rigs, the Blc05's we have been crunching take very consistently 180 secs. Those GPUs have an APR of 900GFlops so the total work done should be 900 x 180 = 162,000. If you calculate the value of a cobblestone by the definition I found it comes to 864GFlops, so the credit for those WUs should have been 162,000 / 864 = 187.5. The credit awarded by CreditScrew? That would be 50 to 60 ( as others have pointed out, it is not even consistent) but that is where we are at now. 3 weeks ago it would have been at least 50% higher, though no more consistent. The only thing that is not clear is how it manages to be of use to the project when it is neither accurate nor consistent.

Stephen

:) Feeling better now :)

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.

. . Wouldn't the diversity of apps for the various devices achieve that result as well or better? Assigning wingmen on the basis of using a different app/OS rather than sticking it behind a device which is poorly suited for would be far more efficient.

Stephen

? ?

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

. . If my memory serves me that point has been raised before but never progressed.

Stephen

? ?

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

He has acknowledged a problem with credit, though: credit is a BOINC-wide problem, not a SETI problem. Issue #2132