Okay, I think Sutaru is talking about this situation.

http://setiathome.berkeley.edu/result.php?resultid=1182474287

against

http://setiathome.berkeley.edu/result.php?resultid=1196522444

There has been an 10% drop in claimed credit even for Cuda.

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

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

Okay, I think Sutaru is talking about this situation.

http://setiathome.berkeley.edu/result.php?resultid=1182474287

against

http://setiathome.berkeley.edu/result.php?resultid=1196522444

There has been an 10% drop in claimed credit even for Cuda.

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

This drop was pretty abrupt between the end of march and beginning of april.

Okay, I think Sutaru is talking about this situation.

http://setiathome.berkeley.edu/result.php?resultid=1182474287

against

http://setiathome.berkeley.edu/result.php?resultid=1196522444

There has been an 10% drop in claimed credit even for Cuda.

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

This drop was pretty abrupt between the end of march and beginning of april.

... 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.

---

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

---

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??

---

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.

My equipment: Q6600 + GTX 260, XP SP3
Wingman equipment: Q6600 + GeForce 8800, Vista SP2

Any ideas why my wingman requested such a small credit??

(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

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.

---

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 :)

---

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.

---

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.

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.

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.

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.

---

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.

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.

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.

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.

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.

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

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.

---

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.

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

Me for one, though I did do a couple hours by mistake ... but am now back to quiet ...

I think the last thing they should be saying is they need more users.

The system can't cope as it is.

---

In past a MB AR=0.44x WU got 42.x credits.

Now the same MB AR get 38.x credits?


WHY ??

..ohhh..

..now down to 36.x credits.. :-(

---

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