Message boards :
Number crunching :
again less credits?
Message board moderation
Previous · 1 · 2 · 3 · 4 · 5 . . . 7 · Next
Author | Message |
---|---|
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Okay, I think Sutaru is talking about this situation. Right, the later flopcounter value is ~0.008 percent higher but the claimed credits dropped by ~9.93 percent. That's with sent dates 24 days apart, though, so doesn't really indicate a very abrupt change. Thanks for reminding about the CUDA apps claiming high on midrange and lower work, though, that's another factor which tends to drive the server-side adjustment lower. And we've had a long run without many high angle range shorties. Joe |
MonorailPilot Send message Joined: 12 May 99 Posts: 8 Credit: 4,422,543 RAC: 0 |
Two work units below, processed by the same computer with the same optomized version. AR was as close as I could find. The flopcounters are with 0.0135% of each other. Claimed credit differs by almost 10% http://setiathome.berkeley.edu/workunit.php?wuid=426309055 Created 22 Mar 2009 6:16:50 UTC Sent 22 Mar 2009 7:15:16 UTC Received 26 Mar 2009 15:21:08 UTC Work Unit Info: ............... Credit multiplier is : 2.85 WU true angle range is : 0.447918 Flopcounter: 15324401819761.402344 Spike count: 1 Pulse count: 0 Triplet count: 0 Gaussian count: 0 </stderr_txt> ]]> Claimed credit 42.2724031908574 Granted credit 42.0599024766647 application version 6.03 http://setiathome.berkeley.edu/result.php?resultid=1195705596 Created 2 Apr 2009 14:11:55 UTC Sent 2 Apr 2009 15:43:53 UTC Received 6 Apr 2009 15:12:41 UTC Work Unit Info: ............... Credit multiplier is : 2.85 WU true angle range is : 0.448090 Flopcounter: 15322344690483.332031 Spike count: 7 Pulse count: 0 Triplet count: 1 Gaussian count: 0 </stderr_txt> ]]> Claimed credit 38.4404769585742 Granted credit 38.4404769585742 |
MonorailPilot Send message Joined: 12 May 99 Posts: 8 Credit: 4,422,543 RAC: 0 |
Okay, I think Sutaru is talking about this situation. This drop was pretty abrupt between the end of march and beginning of april. |
1mp0£173 Send message Joined: 3 Apr 99 Posts: 8423 Credit: 356,897 RAC: 0 |
Okay, I think Sutaru is talking about this situation. ... and we're looking at a tiny sample -- four work units. We also need to look at all of the results for a given WU, since the credit multiplier is probably based on the multiplier in effect on the day the most recent result was created, and BOINC will issue the lower credit. But please pay attention to what Joe said. We know that work units pay at different rates for different angle ranges. This comes from the myth that a floating point "add" and a floating point "cos()" take the same amount of work, and that the instruction mix is the same for all angle ranges. If we have a long run of high-paying (high angle range shorties) work, then that will cause an artificial inflation in the credit rate. When we go back to "normal" work, that inflation will be "given back" and the credit rate will fall. The fix is to lower the multiplier on those high angle range shorties to bring them in line with normal work. |
Dirk Sadowski Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
I looked in my pending credits.. [incl. the CUDA overclaim] I write here now the WUs with the date of the drop of credits. Sent/Received is from the Berkeley server. -------------------------------------- Sent 20 Mar 2009 5:20:35 UTC Received 27 Mar 2009 22:38:15 UTC WU true angle range is : 0.447237 Claimed credit 58.5810860151183 -------------------------------------- Sent 22 Mar 2009 15:05:09 UTC Received 28 Mar 2009 0:19:42 UTC WU true angle range is : 0.447813 Claimed credit 57.8383888181927 -------------------------------------- Sent 24 Mar 2009 15:38:31 UTC Received 2 Apr 2009 10:12:33 UTC WU true angle range is : 0.447719 Claimed credit 57.2916079983226 -------------------------------------- Sent 27 Mar 2009 8:39:12 UTC Received 2 Apr 2009 16:03:34 UTC WU true angle range is : 0.447802 Claimed credit 55.6977834436177 -------------------------------------- Sent 2 Apr 2009 4:54:10 UTC Received 3 Apr 2009 8:37:39 UTC WU true angle range is : 0.443160 Claimed credit 53.6671791022755 -------------------------------------- Sent 2 Apr 2009 10:12:33 UTC Received 3 Apr 2009 23:46:16 UTC WU true angle range is : 0.448095 Claimed credit 52.8411965792529 -------------------------------------- EDIT: BTW. I could also post my whole pending credit list.. with result id and WU id. But.. current I have ~ 42,000 pendings.. so it's a 'small' list.. ;-D |
PeterRehm Send message Joined: 12 Jul 99 Posts: 13 Credit: 1,268,024 RAC: 0 |
Got a strange result with wu 1195924567. My CUDA time = 275.39 and wingman CUDA time = 40.89 (wow!). My requested credit = 52.85 and wingman requested credit = 2.47 (yep 2.47!). Naturally I received 2.47 as credit for the unit. Wow, I've never received that little for a wu. My equipment: Q6600 + GTX 260, XP SP3 Wingman equipment: Q6600 + GeForce 8800, Vista SP2 Any ideas why my wingman requested such a small credit?? |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Got a strange result with wu 428974350. My CUDA time = 275.39 and wingman CUDA time = 40.89 (wow!). My requested credit = 52.85 and wingman requested credit = 2.47 (yep 2.47!). Naturally I received 2.47 as credit for the unit. Wow, I've never received that little for a wu. (added links within quote) The "Flopcounter: 21066167523394.273000" is identical for both results, so the problem was either in converting that to fpops_cumulative or reporting that to the BOINC core client. My guess is the reporting to BOINC quit early for some reason so the 2.47 is based on only the first part of the work. The low claim is from Raistmer's V10, I've saved text copies of the two Task Details pages in case they are purged before he has a chance to look. I think it's about 3:50 A.M. where he lives. Joe |
Miklos M. Send message Joined: 5 May 99 Posts: 955 Credit: 136,115,648 RAC: 73 |
My RAC used to be above 9000, it is now nearing 7000 and i changed nothing here. Major drop in RAC since the start of April. At this rate we shall get 1 RAC per day, lol. |
Salvador Lopez Send message Joined: 20 May 99 Posts: 12 Credit: 2,183,995 RAC: 0 |
I think the real reason behind is of economical reasons... the graph of my recent credit has almost exactly the same trend as the Dow and others... since January. Kind of depressing :) |
BarryAZ Send message Joined: 1 Apr 01 Posts: 2580 Credit: 16,982,517 RAC: 0 |
One payoff for SETI, given the load issues they have been coping with over the past months, the reduced credits for GPU work units (I don't think CPU work unit credits have been reduced) may have the effect of encouraging folks to reallocate GPU resources to other projects. Milkyway (one of the few with an Optimized ATI GPU application) is about to launch a Cuda application this week. I am assuming that the SETI credit controllers won't be seeking to impose their reduced GPU credit approach on other GPU projects. |
W-K 666 Send message Joined: 18 May 99 Posts: 19322 Credit: 40,757,560 RAC: 67 |
One payoff for SETI, given the load issues they have been coping with over the past months, the reduced credits for GPU work units (I don't think CPU work unit credits have been reduced) may have the effect of encouraging folks to reallocate GPU resources to other projects. Milkyway (one of the few with an Optimized ATI GPU application) is about to launch a Cuda application this week. When the credits are reduced, they are reduced for cpu and gpu crunching. So it is the gpu crowd driving away the cpu only people. |
BarryAZ Send message Joined: 1 Apr 01 Posts: 2580 Credit: 16,982,517 RAC: 0 |
I am not sure I understand that -- it would seem if there are other GPU projects (and there are), that folks running gpu setups might also migrate. For me, I reverted two workstations from gpu to cpu (I'm running the low end 9400GT on those two workstations), but I also reduced resource share. I'm not inclined to lay out big bucks for high end GPU's simply to pump up credits (I'm not a gamer and those high end cards really pay off for gamers). Besides, with Malaria back on line (at least with plentiful test work units) I have a home for those CPU cycles.
|
W-K 666 Send message Joined: 18 May 99 Posts: 19322 Credit: 40,757,560 RAC: 67 |
I am not sure I understand that -- it would seem if there are other GPU projects (and there are), that folks running gpu setups might also migrate. Eric's automatic credit adjustment relies on the original benchmark * time = credit calculation. Therefore if the time for gpu processing is wrongly reported very low then the average time going into that formula will decrease the credit granted for all MB tasks. |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
Since that credit adjustment selects the median host, GPU crunching should not have much effect unless more than half the hosts are using it. I've been looking at the calculate_credit_multiplier script and don't really see how CUDA can be having much effect, but someone skilled with SQL might spot something I've missed. Here's a description of what I see: 1. The script first gets 10000 recent results. That step appears to work through the host list simply picking out results which have validated but are still in the BOINC database. I think that may mean that hosts with high hostid values may not be well represented, which may deemphasize hosts running CUDA somewhat. Results with 0 granted credit are excluded, as are ones which were reported more than 30 days ago. 2. The second step merges results. If there are multiple results for a host they are combined, the credit rate for each host is calculated from the sum of its granted credit divided by the sum of cpu time. If my 200 MHz host is in the list it gets as much weight as those at the other end of the speed range. Selection of the median host is effectively just finding the middle of this merged list. 3. Finally, the ratio of that median host's bench/granted credit rate is combined with the most recent previous value in the table to make the entry for this new day. If the script is run daily at the exact same time, 1/30 of the median host's ratio is added to 29/30 of the previous value. One possibility I see is that the merged list could be too short to be statistically good if the original selection of results included a lot of hosts turning in hundreds of results. My guess at this point is that the credit decline has more to do with work mix than CUDA, but it's not a well-founded guess. Joe |
BarryAZ Send message Joined: 1 Apr 01 Posts: 2580 Credit: 16,982,517 RAC: 0 |
OK -- ok so the effect (within SETI) is to reduce credits for GPU and MB tasks. Fair enough. Not a big deal as it isn't as if unilateral changes (automated or not) get imposed or pushed on other BOINC projects (just as changes in other projects don''t get imposed or pushed on SETI). Again, if the overall effect is to reduce credit payouts then one of the possible positive side effects would be to encourage folks to spread their CPU & GPU cycles around to other BOINC projects -- which would help SETI by reducing the load here (as there have been a plethora of comments regarding how close to the load edge SETI is). Eric's automatic credit adjustment relies on the original benchmark * time = credit calculation. Therefore if the time for gpu processing is wrongly reported very low then the average time going into that formula will decrease the credit granted for all MB tasks. |
W-K 666 Send message Joined: 18 May 99 Posts: 19322 Credit: 40,757,560 RAC: 67 |
OK -- ok so the effect (within SETI) is to reduce credits for GPU and MB tasks. Fair enough. Not a big deal as it isn't as if unilateral changes (automated or not) get imposed or pushed on other BOINC projects (just as changes in other projects don''t get imposed or pushed on SETI). Again, if the overall effect is to reduce credit payouts then one of the possible positive side effects would be to encourage folks to spread their CPU & GPU cycles around to other BOINC projects -- which would help SETI by reducing the load here (as there have been a plethora of comments regarding how close to the load edge SETI is). Not that sure wishes at this time Seti wishes to off load some, or parts of some, hosts to other projects. See Tech News Hannah I quote: We're also finding that we don't have the processing power we'd like. It seems like we lost a lot of active users over the past few months.- Matt, Apr 16 2009 |
Paul D. Buck Send message Joined: 19 Jul 00 Posts: 3898 Credit: 1,158,042 RAC: 0 |
Me for one, though I did do a couple hours by mistake ... but am now back to quiet ... |
SATAN Send message Joined: 27 Aug 06 Posts: 835 Credit: 2,129,006 RAC: 0 |
I think the last thing they should be saying is they need more users. The system can't cope as it is. |
Dirk Sadowski Send message Joined: 6 Apr 07 Posts: 7105 Credit: 147,663,825 RAC: 5 |
..ohhh.. ..now down to 36.x credits.. :-( |
Josef W. Segur Send message Joined: 30 Oct 99 Posts: 4504 Credit: 1,414,761 RAC: 0 |
On 12 Aug 2008 Eric posted "credit multipliers are 0.887 for S@H and 0.993 for Astropulse". Yesterday I calculated the multipliers for work sent 22 May 2009 as 0.748 for S@H and 0.955 for Astropulse v5. I don't know why the S@H Enhanced multiplier has decreased that much. By design, CUDA shouldn't effect it unless a majority of the sampled hosts are using CUDA. My best guess is we're just seeing a side effect of "Moore's Law" and the median host is actually processing the work more efficiently. An alternative guess is that the benchmarks in BOINC 6.6.x have shifted enough to have some effect, though that would tend to affect both Enhanced and Astropulse equally. Joe |
©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.