A very steep decline in Average Credits!!!

Message boards : Number crunching : A very steep decline in Average Credits!!!
Message board moderation

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 . . . 14 · Next

AuthorMessage
Al Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Avatar

Send message
Joined: 3 Apr 99
Posts: 1682
Credit: 477,343,364
RAC: 482
United States
Message 1912844 - Posted: 13 Jan 2018, 18:26:15 UTC - in response to Message 1912782.  
Last modified: 13 Jan 2018, 18:30:30 UTC

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

ID: 1912844 · Report as offensive
Profile Advent42
Avatar

Send message
Joined: 23 Mar 17
Posts: 175
Credit: 4,015,683
RAC: 0
Ireland
Message 1912861 - Posted: 13 Jan 2018, 20:30:07 UTC - in response to Message 1912837.  

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

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

Thank you.
ID: 1912861 · Report as offensive
Profile Advent42
Avatar

Send message
Joined: 23 Mar 17
Posts: 175
Credit: 4,015,683
RAC: 0
Ireland
Message 1912984 - Posted: 14 Jan 2018, 14:18:07 UTC - in response to Message 1912861.  

Also I just noticed that my RAC graph is very similar to my stock graph...:-)...LOL.
ID: 1912984 · Report as offensive
Iona
Avatar

Send message
Joined: 12 Jul 07
Posts: 790
Credit: 22,438,118
RAC: 0
United Kingdom
Message 1913265 - Posted: 15 Jan 2018, 22:19:25 UTC

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!
ID: 1913265 · Report as offensive
Profile Bill G Special Project $75 donor
Avatar

Send message
Joined: 1 Jun 01
Posts: 1282
Credit: 187,688,550
RAC: 182
United States
Message 1913273 - Posted: 15 Jan 2018, 23:52:26 UTC - in response to Message 1913265.  

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
ID: 1913273 · Report as offensive
Profile RueiKe Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 14 Feb 16
Posts: 492
Credit: 378,512,430
RAC: 785
Taiwan
Message 1913307 - Posted: 16 Jan 2018, 7:00:38 UTC

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
ID: 1913307 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13372
Credit: 208,696,464
RAC: 304
Australia
Message 1913309 - Posted: 16 Jan 2018, 7:40:37 UTC - in response to Message 1913307.  
Last modified: 16 Jan 2018, 7:43:50 UTC

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
ID: 1913309 · Report as offensive
rob smith Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer moderator
Volunteer tester

Send message
Joined: 7 Mar 03
Posts: 21021
Credit: 416,307,556
RAC: 380
United Kingdom
Message 1913312 - Posted: 16 Jan 2018, 8:08:20 UTC
Last modified: 16 Jan 2018, 8:08:42 UTC

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?
ID: 1913312 · Report as offensive
Profile Keith Myers Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 29 Apr 01
Posts: 13157
Credit: 1,160,866,277
RAC: 1,873
United States
Message 1913313 - Posted: 16 Jan 2018, 8:08:21 UTC

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)
ID: 1913313 · Report as offensive
Grant (SSSF)
Volunteer tester

Send message
Joined: 19 Aug 99
Posts: 13372
Credit: 208,696,464
RAC: 304
Australia
Message 1913314 - Posted: 16 Jan 2018, 8:26:43 UTC - in response to Message 1913313.  

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
ID: 1913314 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913340 - Posted: 16 Jan 2018, 11:40:08 UTC - in response to Message 1911959.  

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


. . There's always one :)

Stephen

:)
ID: 1913340 · Report as offensive
Profile RueiKe Special Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 14 Feb 16
Posts: 492
Credit: 378,512,430
RAC: 785
Taiwan
Message 1913341 - Posted: 16 Jan 2018, 11:40:22 UTC - in response to Message 1913309.  

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
ID: 1913341 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913344 - Posted: 16 Jan 2018, 11:43:23 UTC - in response to Message 1912259.  

My RAC



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

Stephen

:(
ID: 1913344 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913345 - Posted: 16 Jan 2018, 11:59:14 UTC - in response to Message 1912356.  

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

? ?
ID: 1913345 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913354 - Posted: 16 Jan 2018, 12:08:47 UTC - in response to Message 1912357.  

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

:)
ID: 1913354 · Report as offensive
Al Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Avatar

Send message
Joined: 3 Apr 99
Posts: 1682
Credit: 477,343,364
RAC: 482
United States
Message 1913357 - Posted: 16 Jan 2018, 12:27:18 UTC

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.

ID: 1913357 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913360 - Posted: 16 Jan 2018, 12:35:00 UTC - in response to Message 1912361.  

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 :)
ID: 1913360 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913361 - Posted: 16 Jan 2018, 12:40:12 UTC - in response to Message 1912371.  

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

? ?
ID: 1913361 · Report as offensive
Stephen "Heretic" Crowdfunding Project Donor*Special Project $75 donorSpecial Project $250 donor
Volunteer tester
Avatar

Send message
Joined: 20 Sep 12
Posts: 5557
Credit: 192,787,363
RAC: 628
Australia
Message 1913362 - Posted: 16 Jan 2018, 12:41:43 UTC - in response to Message 1912374.  

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

? ?
ID: 1913362 · Report as offensive
Richard Haselgrove Project Donor
Volunteer tester

Send message
Joined: 4 Jul 99
Posts: 14509
Credit: 200,643,578
RAC: 874
United Kingdom
Message 1913363 - Posted: 16 Jan 2018, 12:50:44 UTC - in response to Message 1912374.  

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
ID: 1913363 · Report as offensive
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 . . . 14 · Next

Message boards : Number crunching : A very steep decline in Average Credits!!!


 
©2022 University of California
 
SETI@home and Astropulse are funded by grants from the National Science Foundation, NASA, and donations from SETI@home volunteers. AstroPulse is funded in part by the NSF through grant AST-0307956.