Message boards :
Number crunching :
A very steep decline in Average Credits!!!
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 · 6 · 7 · 8 . . . 14 · Next
Author | Message |
---|---|
Al Send message Joined: 3 Apr 99 Posts: 1682 Credit: 477,343,364 RAC: 482 |
NorthCup, whatever you do, don't let out the Magic Smoke! That is what all computers run on, you know? ;-) |
Advent42 Send message Joined: 23 Mar 17 Posts: 175 Credit: 4,015,683 RAC: 0 |
How does one do Beta tasks?...:-) Thank you. |
Advent42 Send message Joined: 23 Mar 17 Posts: 175 Credit: 4,015,683 RAC: 0 |
Also I just noticed that my RAC graph is very similar to my stock graph...:-)...LOL. |
Iona Send message Joined: 12 Jul 07 Posts: 790 Credit: 22,438,118 RAC: 0 |
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! |
Bill G Send message Joined: 1 Jun 01 Posts: 1282 Credit: 187,688,550 RAC: 182 |
On the recent 'diet' of work, I've noticed a few things on my 'daily', running the Lunatics applications:- YES SETI@home classic workunits 4,019 SETI@home classic CPU time 34,348 hours |
RueiKe Send message Joined: 14 Feb 16 Posts: 492 Credit: 378,512,430 RAC: 785 |
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 |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
This example of credit granted for a normal WU definitely looks off: 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 |
rob smith Send message Joined: 7 Mar 03 Posts: 22491 Credit: 416,307,556 RAC: 380 |
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? |
Keith Myers Send message Joined: 29 Apr 01 Posts: 13164 Credit: 1,160,866,277 RAC: 1,873 |
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) |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13841 Credit: 208,696,464 RAC: 304 |
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 |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
My RAC is still going up after the server issues in December. . . There's always one :) Stephen :) |
RueiKe Send message Joined: 14 Feb 16 Posts: 492 Credit: 378,512,430 RAC: 785 |
If you go through your results, you'll see quite a few like that. 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 |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
My RAC . . My drop is much much steeper than that :( Stephen :( |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
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 ? ? |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
Thus spake a true credit hound. . . 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 :) |
Al Send message Joined: 3 Apr 99 Posts: 1682 Credit: 477,343,364 RAC: 482 |
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. |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
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. . . 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 :) |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
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 ? ? |
Stephen "Heretic" Send message Joined: 20 Sep 12 Posts: 5557 Credit: 192,787,363 RAC: 628 |
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. . . If my memory serves me that point has been raised before but never progressed. Stephen ? ? |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14676 Credit: 200,643,578 RAC: 874 |
He has acknowledged a problem with credit, though: credit is a BOINC-wide problem, not a SETI problem. Issue #2132DA 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.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. |
©2024 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.