Someone equated the OET points to being on a "roller-coaster ride" and that is exactly what I'm seeing. To me, that has added a bit of interest to working this project that I'm liking.

With no changes in my rigs that are dedicated to OET, yesterday my points were 138,155 (642 Results). Part way into today, the points are already at 288,298 (1,089 Results). I have both hands in the air on this downhill speed dip of the coaster today!

I did notice that I have bunches of those much shorter WUs that have been running with loads more of them in queue. Wooohooo...

For the last 4 days, crunching exclusively OET over 4 machines, this is what I get:

02/15/2015 | 0:060:18:18:41 | 73,090
02/14/2015 | 0:059:04:08:46 | 135,801
02/13/2015 | 0:061:09:30:07 | 406,865
02/11/2015 | 0:065:21:14:15 | 335,238

Completely silly of course, going from 7.25 to 39.7 or +547%, then going to 30.7 or -125%. His I7-5820K would have to be in the 25/hr range under Windows and on Linux 36-40/hr. My Linux fell bck to 14, so flipped back to Windows where it stepped into the spinner of credit cycle at a different point of evolution... it's making 25 again.

OET1_ 0000464_ xZAGP-S_ rig_ 40664_ 0-- 2497409 Valid 2/16/15 06:50:10 2/16/15 17:07:08 1.54 / 1.56 38.4 / 38.4
OET1_ 0000464_ xZAGP-S_ rig_ 34113_ 0-- 2497409 Valid 2/16/15 06:42:00 2/16/15 16:40:14 1.17 / 1.18 29.1 / 29.1
OET1_ 0000464_ xZAGP-S_ rig_ 0904_ 0-- 2497409 Valid 2/16/15 06:10:01 2/16/15 16:31:05 1.06 / 1.08 26.4 / 26.4

Same device, inversed world. Goes to show how SU'd "Credit New" is. Having figured it out, maximizing 'Gflops' on Snurk's sig is a real fun game to play, if I would still play it. It's mostly an exercise of demonstrating how bad it is. Of course demonstrating front of the wailing wall is just that... no ears willing to listen, let alone act. As the admin has often said "launching/maintaining sciences is overarching important" (something to that effect).

A rough theory on how to fix this:

The mitigation to be applied is to use what in part is already done, a credit history per host per app. Take the total credit pool and time run, take the median benchmark of all active hosts and determine credit per second. At CPU level e.g. Q6600, use a fixed factor against the pool, e.g. if pool is having a 5000 total benchmark, and the pool of Q6600 is 7500, use a 1.5. No more outlier BS, someone getting in and out in random points in the credit cycle evolution being over granted or penalized.

The claim is 'faked' **, based on what was recently granted, generally this going in a downward spiral, with those inordinate kicks when the project runtime suddenly changes, up or down. Credit is computed by the server at time of result returning. Then when the wingman returns, it is computed for that device. After that the 2 'claims' are pooled and the average granted to both, except when one of 2 is so off that the outlier rule kicks in, which is when you get 41 hour jobs being granted 0.3 per hour. The mechanism seems in general to gravitate toward the lowest common denominator. See chart above how credit cajoles.

** At some point it was said the 'claim' side was hacked in under Credit New andwould be removed. At other BOINC projects it has been gone for longer. Whence, the comprehension of credit will become even more 'go figure'. It will just be the grant, and no one understanding how the average between the 2 wingman could possibly be arrived at.

Watch the FA@H project. The techs announced they were going to extend the FAHV runtime, of the fairly regular runtime running project. There will be some equilibrium shaking again, you betcha, the more % change the bigger the swingS.