Hi,

The absence of (now returned) GUPPI work has trained the credit system somehow to give more credit for the longer running tasks.

5429769510 	2394133866 	13 Jan 2017, 15:47:02 UTC 	13 Jan 2017, 18:20:39 UTC 	Completed and validated 	205.65 	204.34 	170.14 	SETI@home v8
Anonymous platform (NVIDIA GPU)
5429769381 	2394133991 	13 Jan 2017, 15:47:02 UTC 	13 Jan 2017, 18:15:30 UTC 	Completed and validated 	3.03 	1.68 	1.71 	SETI@home v8
Anonymous platform (NVIDIA GPU)
5429769439 	2394134099 	13 Jan 2017, 15:47:02 UTC 	13 Jan 2017, 18:27:19 UTC 	Completed and validated 	128.37 	127.12 	107.86 	SETI@home v8
Anonymous platform (NVIDIA GPU)
5429769467 	2394134008 	13 Jan 2017, 15:47:02 UTC 	13 Jan 2017, 18:09:42 UTC 	Completed and validated 	205.64 	204.15 	176.48 	SETI@home v8
Anonymous platform (NVIDIA GPU)

Those 200 s tasks are guppi.

I'm sure the effect will fade away when the proportion of Arecibo work gets lower and the APR returns from 1800 to 1300 or below.

---

To overcome Heisenbergs:
"You can't always get what you want / but if you try sometimes you just might find / you get what you need." -- Rolling Stones

The absence of (now returned) GUPPI work has trained the credit system somehow to give more credit for the longer running tasks.

Which is bad IMHO.
Ideally you get paid a certain amount for doing a certain amount of work, what you get paid shouldn't vary because it takes more or less time to do. The more work you can do, then the more you can earn.


Edit-
eg- I had 2 WUs that took me the same time to crunch (within 2 secs). One paid 166, the other 99. I did the same amount of work for each of them, so the amount paid should be the same.

---

Grant
Darwin NT

By the time most CPU's get back to doing Guppi's again that will probably change back to what it was before.

Cheers.

But that is the exact definition of the "amount of work":

work = CPU-time/GPU-time (measured while executing) x flops/sec (measured by benchmarks beforehand)

So if some bug leads to longer runtimes, a higher amount of work is assumed - thats why only the lowest valid credit claim of a WU is awarded to all. If 2 buggy machines accidently meet each other - well thats simply good luck for the credit count of these 2 machines, but bad luck for the project (as actually less work gets done).

But that is the exact definition of the "amount of work":

work = CPU-time/GPU-time (measured while executing) x flops/sec (measured by benchmarks beforehand)

So if some bug leads to longer runtimes, a higher amount of work is assumed - thats why only the lowest valid credit claim of a WU is awarded to all. If 2 buggy machines accidently meet each other - well thats simply good luck for the credit count of these 2 machines, but bad luck for the project (as actually less work gets done).

If you can understand CreditNew you may understand why it's referred to by many here as "CreditScrew" or "RandomNumberGenerator". ;-)

By the time most CPU's get back to doing Guppi's again that will probably change back to what it was before.

And as predicted, it has.

Cheers.