Message boards :
Number crunching :
Why does CreditFew Award Fewer Credits when my GPU is matched with a CPU than with another GPU?
Message board moderation
Author | Message |
---|---|
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Since the Arecibo VLARs were changed to run on the GPUs I've been paying close attention to the Credits awarded. On MY machines it is apparent that generally when MY nVidia GPUs are matched with a CPU they are awarded MUCH less Credit than when MY nVidia GPUs are matched with another GPU. Overall, partly due to this BUG, the credit since the VLAR change has been Fewer than previous. If this BUG with CreditFew were fixed, the awarded credit should be closer to what was 'normal' back before the VLAR change. It also MIGHT help with awarded credit in General. It shouldn't be that difficult for whomever is responsible for coding CreditFew as it's a pretty specific problem. Credit awarded for Two GPUs is about 30% Higher than credit awarded for the Same GPU matched with a CPU. Anyone that has the desire can see the evidence for themselves, just compare the Credit awarded for Two GPUs against that for the Same GPU against a CPU. From this Host, http://setiathome.berkeley.edu/results.php?hostid=6796479&offset=460 Against GPUs; 6610549051 6069172 3 May 2018, 14:36:04 UTC 4 May 2018, 3:10:19 UTC Completed and validated 2,523.70 358.30 159.68 SETI@home v8 v8.20 (opencl_ati5_mac) x86_64-apple-darwin 6610549052 6796479 3 May 2018, 14:36:03 UTC 3 May 2018, 21:09:27 UTC Completed and validated 387.86 383.31 159.68 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610523967 8316820 3 May 2018, 14:20:33 UTC 4 May 2018, 3:54:11 UTC Completed and validated 901.45 312.83 160.13 SETI@home v8 v8.22 (opencl_nvidia_SoG)x86_64-pc-linux-gnu 6610523968 6796479 3 May 2018, 14:20:31 UTC 3 May 2018, 20:53:56 UTC Completed and validated 374.73 370.88 160.13 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610467691 6796479 3 May 2018, 13:44:19 UTC 3 May 2018, 20:07:16 UTC Completed and validated 387.30 382.16 173.92 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610467692 7276615 3 May 2018, 13:44:17 UTC 3 May 2018, 20:18:55 UTC Completed and validated 1,354.00 1,342.12 173.92 SETI@home v8 v8.22 (opencl_nvidia_SoG) windows_intelx86 Against CPUs; 6610681378 6796479 3 May 2018, 15:53:41 UTC 3 May 2018, 22:42:36 UTC Completed and validated 387.18 384.22 111.32 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610681379 8382678 3 May 2018, 15:53:44 UTC 4 May 2018, 1:50:29 UTC Completed and validated 7,813.49 325.39 111.32 SETI@home v8 v8.20 (opencl_intel_gpu_sah) windows_intelx86 6610672569 7957109 3 May 2018, 15:48:30 UTC 3 May 2018, 22:47:49 UTC Completed and validated 14,998.12 14,992.77 106.86 SETI@home v8 v8.08 (alt) windows_x86_64 6610672570 6796479 3 May 2018, 15:48:26 UTC 3 May 2018, 22:37:26 UTC Completed and validated 388.10 385.06 106.86 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610584746 6796479 3 May 2018, 14:56:45 UTC 3 May 2018, 21:35:17 UTC Completed and validated 369.79 365.19 113.33 SETI@home v8 Anonymous platform (NVIDIA GPU) 6610584747 8373390 3 May 2018, 14:56:44 UTC 4 May 2018, 2:37:34 UTC Completed and validated 13,749.34 6,957.17 113.33 SETI@home v8 v8.00 x86_64-pc-linux-gnu |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
Why does CreditFew Award Fewer Credits when my GPU is matched with a CPU than with another GPU? Because that was the way it was designed. Basically it is the anti cheating part of the design combined with it's fanciful ideas about efficiency (a GPU is considered inefficient compared to a CPU because the GPUs actual FLOPs doesn't come as close to it's (guesstimated) Peak FLOPs as a CPUs Actual/Peak FLOPs ratio- the fact a GPU can do 10 or 20 times the amount of work a CPU can do over the same time period doesn't come in to it) both not working as they should. End result, different Credit awarded depending on who your wingman is. It is a known design flaw. From the BOINC Wiki on Credit New. •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 |
rob smith Send message Joined: 7 Mar 03 Posts: 22188 Credit: 416,307,556 RAC: 380 |
As Grant says - the whole logic around guessing the FLOPs/task for GPUs is suspect, and leads to an underestimate for FLOPs by GPUs. Another thing to consider is that CPUs aren't hit as badly, in terms of task run time, as GPUs so the bit of logic that decides which result is the canonical result will tend to vote for the CPU task - all in all it comes down to some poor design choices and some slightly suspect implementation working against us, the user. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
iwazaru Send message Joined: 31 Oct 99 Posts: 173 Credit: 509,430 RAC: 0 |
Ha ha :) What are you guys all on about? Maybe it's late and I should retire my keyboard but shouldn't you have to establish why the CPU credit is incorrect? From where I'm standing it looks like the CPU results are correct and the GPU paired results are overpaid :) No seriously. - Alex Edit: What you need to do is look at CPU pairs and see if they are higher than CPU with GPU. Then you've proven it wrong. |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
From where I'm standing it looks like the CPU results are correct and the GPU paired results are overpaid :) As I've said many times, perhaps you should look at the results BEFORE making a post? It's simple, compare the results from other Arecibo GPU tasks and consider the run-times. Here are a few; Name 30ap18aa.27800.9887.14.41.37_0 - Run time 2 min 53 sec - Credit 69.25 Name 30ap18aa.25506.9069.15.42.100_0 - Run time 2 min 56 sec - Credit 81.96 Name 28ap18aa.24424.22971.9.36.121_2 - Run time 2 min 50 sec - Credit 77.74 So, a "normal" Arecibo task runs for around 3 minutes and scores around 75 points. The Arecibo VLARs run a little over twice as long so should score about twice as much. They do score twice as much when paired with GPUs, the problem is they Don't when paired with CPUs. So far, all I'm seeing is the typical 'yes we know it's a problem, but no one wants to fix it'. We've seen this before. It's nice we recently had the Work fetch problem, and the Weekly Outrage problem Fixed. So, how about a three-fer? Can we Please have the Long standing Credit problem addressed? Hasn't this gone on long enough? |
iwazaru Send message Joined: 31 Oct 99 Posts: 173 Credit: 509,430 RAC: 0 |
No offense dude, you didn't understand a word I said. The Arecibo VLARs run a little over twice as long so should score about twice as much. Do Arecibo VLARs score twice as much on two CPUs running stock apps? If yes then: you've found yourself a bug. If no then: you've managed to outfox CreditNew into paying more credit than you deserve. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
Do Arecibo VLARs score twice as much on two CPUs running stock apps? Sometimes. That also is part of the problem with Credit New. Grant Darwin NT |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
No offense dude, you didn't understand a word I said.Dude, I'm the One that is responsible for a number of Stock SETI Apps, I know a little about the Apps. I suggest YOU look at the Results yourself before making any further posts. ..you've managed to outfox CreditNew into paying more credit than you deserve...ROFLMAO |
iwazaru Send message Joined: 31 Oct 99 Posts: 173 Credit: 509,430 RAC: 0 |
TBar chill. I haven't been away THAT long. I still remember who you are. I haven't got any CPU VLARs in my Valid Tasks ATM so can one of you two show me what you are talking about? - Grant says "sometimes". If sometimes means 1 out of 10 then there is no reason for anyone to ever get double the credit no matter what app, device, runtime or combo thereof. - You say "I suggest YOU look at the Results yourself" and since I have no results to look at, I take it you are saying that it'll happen 9 out of 10 times. So who of the two of you is right? Or better yet, TBar could you just please do a chart like the ones you've done above but with two paired CPU apps so we could have a look? |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
- Grant says "sometimes". If sometimes means 1 out of 10 then there is no reason for anyone to ever get double the credit no matter what app, device, runtime or combo thereof. Both. I was answering your question about what happens when 2 CPUs are paired with each other. Tbar was talking about what happens when a GPU & CPU are paired, compared to 2 GPUs paired. And the fact is it's not 1 out of 10 for 2 CPUs to give different Credit for a given WU, under Credit New the amount of Credit you will get depends on what application you are running, what application the other person is running. And as applications vary between hardware & operating systems, Credit granted varies a lot. That has been the problem of Credit New from day 1. A bit of history. With Seti Classic the only way of being recognised for the amount of work you did was the number of results you returned. Given 1 WU (Work Unit) might last 3 seconds and another 8 hours, it wasn't the best of systems. So BOINC came about, with Credit being given for work done, not just the number of WUs processed. The idea was to award Credit, based on the amount of processing done. Since the processing is mathematical, FLOPS (Floating Operations Per Second) was used to determine how much work as done, and so Credit awarded. The first Credit system had some issues (which at the time seemed bad, but actually aren't as bad as Credit New IMHO). The second Credit system actually counted the number of FLOPs required to process a WU. There was a scaling factor so the payout for processing a given work unit was on par with the original Credit system. With this system it didn't matter what hardware you had, what operating system you were using, or what application you used to process the WU. If it validated, you got Credit. And that Credit was the same, regardless of what hardware, software, OS you or your wingman were using. Then came Credit New. Not only did the amount of Credit awarded for a given WU take a dive, but the severity of the dive varied depending on the hardware, OS & application used. It's is screwed. Totally & utterly. Hence people generally call it Credit Screw- because it's so broken, and it screws everyone out of the Credit they should be getting. Grant Darwin NT |
iwazaru Send message Joined: 31 Oct 99 Posts: 173 Credit: 509,430 RAC: 0 |
Grant thank you, all that explaining could not have been easy so the effort is deeply appreciated. You are not alone however. I've read that CN Wiki page too... more times than I care to remember :) You guys are gonna hate me for saying this but I went through 1053 valid tasks on that PC linked above and if these two tasks are Arecibo VLARs... 6597337440 6796479 28 Apr 2018, 0:55:39 UTC 29 Apr 2018, 10:20:10 UTC Completed and validated 7,713.83 7,713.35 102.82 SETI@home v8 Anonymous platform (CPU) 6597337441 8190758 28 Apr 2018, 0:55:45 UTC 2 May 2018, 8:58:01 UTC Abandoned 0.00 0.00 --- SETI@home v8 v8.08 (alt) windows_x86_64 6607997478 8376273 2 May 2018, 12:20:48 UTC 4 May 2018, 11:24:07 UTC Completed and validated 3,992.00 3,986.16 102.82 SETI@home v8 v8.00 x86_64-pc-linux-gnu 6541061436 8039508 6 Apr 2018, 4:49:42 UTC 5 May 2018, 4:15:56 UTC Completed and validated 12,835.78 11,311.08 111.30 SETI@home v8 v8.08 (alt) windows_x86_64 6541061437 6796479 6 Apr 2018, 4:49:41 UTC 7 Apr 2018, 5:22:04 UTC Completed and validated 7,635.94 7,635.34 111.30 SETI@home v8 Anonymous platform (CPU) ... then it really does look like it's the GPU paired tasks that are the outliers. So yeah, from where I'm standing it [still] looks like the CPU results are correct and the GPU paired results are overpaid :) |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
... then it really does look like it's the GPU paired tasks that are the outliers. There are no GPU paired tasks in what you posted there. So you really need to post the tasks you're talking about for us to have the slightest chance of any of us making sense of what you are saying. Because how GPUs that earn less credit than CPUs for a given WU can be overpaying, I have no idea. Edit- OK, you're referring to the comparisons Tbar posted earlier. And there aren't any CPU pairs there. OK, with the examples Tbar posted, and the ones you posted (assuming they are of highly similar angle ranges), the CPU pairs you posted have been underpaid. The GPU pairs are inline with what should be paid, as the Credit for non VLAR Arecibo work was roughly half the value granted for the WUs Tbar posted. Grant Darwin NT |
rob smith Send message Joined: 7 Mar 03 Posts: 22188 Credit: 416,307,556 RAC: 380 |
What you are observing is a well know flaw in the way CreditNew is calculated. It does not handle GPUs correctly, that is either "fairly" or "consistently". There are mechanisms within the credit calculation that are supposed to cope with GPUs, but they fail dramatically due to the shear range of devices and applications in use, and that is compounded by the fact a fair number of users run multiple tasks on their GPUs. Grant, in his post, summed the situation up "It's is screwed. Totally & utterly." It is also worth considering that the performance range of GPUs is very dramatic - Last time I looked it was in excess of 10:1 between the fastest and slowest, even when running the same application. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
Richard Haselgrove Send message Joined: 4 Jul 99 Posts: 14650 Credit: 200,643,578 RAC: 874 |
The key line in this discussion is The Arecibo VLARs run a little over twice as long so should score about twice as much.The bit in yellow is true, but only for NVidia GPUs. On CPUs (and, I believe, AMD GPUs) they run about the same time. So, the 'should' is problematic, and that's what we're discussing here. In general terms, a VLAR is pretty much the same amount of work as any standard task. So, if we're rewarding output, they should get the same amount of credit, But NVidia GPUs find them tough going - they work harder, but more inefficiently. So if we're rewarding effort, the NVs would get a higher credit. Effort or output? You can't reward both with a single number. The scientists have chosen to reward output: those are the rules of the game, however well or badly implemented. When GPU is matched against GPU, you get a bonus for effort, but that's just luck. |
Grant (SSSF) Send message Joined: 19 Aug 99 Posts: 13727 Credit: 208,696,464 RAC: 304 |
In general terms, a VLAR is pretty much the same amount of work as any standard task. So, if we're rewarding output, they should get the same amount of credit, Bang! Richard's hit another bull's eye. So iwazaru is correct, the GPU pairs are being overpaid, compared to other pairs (although I will still argue the others are all actually being underpaid...). If the Credit system were to work as it should, the GPU pairs should be getting the same Credit as any other pairings for a given AR WU. They've all done the same work, some just took longer than others. And any given CPU pair should get the same Credit for the same AR WU as any other CPU pair, which unfortunately doesn't happen. Grant Darwin NT |
kittyman Send message Joined: 9 Jul 00 Posts: 51468 Credit: 1,018,363,574 RAC: 1,004 |
And the kitties just say...."It is what it is. Until it isn't." Meow. "Freedom is just Chaos, with better lighting." Alan Dean Foster |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
So yeah, from where I'm standing it [still] looks like the CPU results are correct and the GPU paired results are overpaid :)Well, let's go back a ways and see what was going on a couple of Years ago; Posted: 21 Apr 2016, 16:17:29 UTCHmmm, it looks to be about the same now. I see a few AR .44 tasks scoring 100 points, Run time 2 min 52 sec - CPU time 2 min 48 sec - Credit 103.38 - WU true angle range is : 0.440074 If these are overpaid, they have been overpaid for quite some time. Now WE are being fed tasks that take TWICE as long to run and being told it's 'normal'. Run time 6 min 29 sec - CPU time 6 min 21 sec - Credit 107.96 - WU true angle range is : 0.009430 Sorry, that won't fly. If this isn't corrected SOON, I can assure you there will be people Aborting these tasks in droves. Also, MY ATI cards run these VLARs about the same as MY NV GPUs. It's slightly better, taking just under TWICE as long to run the 'New' VLARs. I've looked around and other people are receiving the same results with their ATI/AMD GPUs. So, I don't know where the idea the ATI GPUs are that much better on the VLARs came from, I'm Not seeing it. That means EVERYONE is sharing in the misery, not just the NV users. |
rob smith Send message Joined: 7 Mar 03 Posts: 22188 Credit: 416,307,556 RAC: 380 |
This apparent conflict in execution time vs WU type vs GPU type is down the the way the nVidia GPUs are designed - the silicon isn't as good at doing the calculations required for the small angle range Arecibo tasks. This manifests as an reduction credit per hour for such tasks being run on nVidia GPUs. Further, don't forget that until recently running such tasks on an nVidia GPU would suffer massive (x10 or more) extended run times - x2 is livable with, and indeed the majority "fit and forget" user won't even notice the issue. Weren't some of those moaning today about the extended run times on their nVidia GPUs those that were moaning when they got no work because the project deemed their GPUs unsuitable to execute such tasks? Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
TBar Send message Joined: 22 May 99 Posts: 5204 Credit: 840,779,836 RAC: 2,768 |
Again, the ATI/AMD GPUs also run the Arecibo tasks Slower. Here are a few examples; Fiji ; Run time 5 min 29 sec - CPU time 4 min 35 sec - Credit 96.14 - ar=0.427212 Run time 7 min 53 sec - CPU time 4 min - Credit 113.06 - ar=0.008547 580 ; Run time 8 min 48 sec - CPU time 5 min 45 sec - Credit 96.47 - ar=0.440159 Run time 13 min 21 sec - CPU time 4 min 33 sec - Credit 111.52 - ar=0.011127 Absolutely Nothing wrong with the Silicon in NV GPUs, the problem with the First CUDA App was strictly a BUG in the SETI App. That Bug isn't in the Special App, which is why a 30 watt GTX 750 Ti gives about the Same times as a RX 580. Most people haven't become aware of the Credit difference, when they do, you won't hear from the ones that will Abort tasks. You will just start seeing a large number of 'Errors', such as this, https://setiathome.berkeley.edu/results.php?hostid=7284511&state=6&appid= Has anyone considered Credit based on Angle Range? It does seem to be the determining factor in GPU run-times. |
rob smith Send message Joined: 7 Mar 03 Posts: 22188 Credit: 416,307,556 RAC: 380 |
Ah Wedge009, you chose the one person who is famed for his aborting of thousands of tasks - when ever he sees something he doesn't like/want he just aborts the lot - last time I saw him do this it was APs, on another occasion it was BLP. He is a long way removed from the average user who will NEVER take any note of what is running on their computers. Bob Smith Member of Seti PIPPS (Pluto is a Planet Protest Society) Somewhere in the (un)known Universe? |
©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.