Many times restarted @100%, the same counts every WU, too many credit claimed for too small computation time for such CPU.
http://setiathome.berkeley.edu/results.php?hostid=2046662&offset=120

Resuts are not validated, but...
Maximum daily WU quota per CPU 100/day
Why quota doesn't go down ????

Whatever the problem is, the host is not being granted any credit for the work....

---

"Freedom is just Chaos, with better lighting." Alan Dean Foster

Yes, but quota still 100 WU per day - that is the problem (it leech WUs at 17sec per WU rate! )

Yes, but quota still 100 WU per day - that is the problem (it leech WUs at 17sec per WU rate! )

My guess a virtual machine gone wild.

Why it is not stopped from getting more work may be related to this.

IIRC the work unit quota is 100 per CPU core.


UncleVom

---

I think the quota only goes down for errors. These are marked as "Success" even tho' he is indeed returning bad results. It looks like he got 100 for June 22, then nothing for four hours since, so he seems to have hit the quota. Glad he is not running a quad!

IIRC the work unit quota is 100 per CPU core.

It is 100 per core, but I believe BOINC still treats the number as a whole, per system. So if a single core returns a bad result, it will be lowered to 99 per core, even on a quad core.



As for a possible answer to the question "How is this person allowed to download so much while returning bad results?" Could it be a bad overclock returning incorrect results instead of invalid results? I think the quota only covers a CPU returning invalid results but does nothing against incorrect results.

I think the quota only goes down for errors. These are marked as "Success" even tho' he is indeed returning bad results.
...

That's right. Whatever has gone wrong with the host began on June 17, and the 5.8.16 core client doesn't recognize there's a problem. I think the stderr.txt stuff indicates the core client hasn't been able to clear out the slot, so the app is running WUs starting from the leftover final checkpoint. More recent versions of BOINC do checking and create a new slot if they were unable to clear an old one.

                                                                  Joe

I think the quota only goes down for errors. These are marked as "Success" even tho' he is indeed returning bad results.
...

That's right. Whatever has gone wrong with the host began on June 17, and the 5.8.16 core client doesn't recognize there's a problem. I think the stderr.txt stuff indicates the core client hasn't been able to clear out the slot, so the app is running WUs starting from the leftover final checkpoint. More recent versions of BOINC do checking and create a new slot if they were unable to clear an old one.

                                                                  Joe

I thought "success" merely meant that the WU completed and was successfully returned to the server, not necessarily meaning a 'good' or 'bad' result.

Seems like BOINC is not able to clean up the working slot directory, so each unit uses an old result/state file, "restarts" at 99.78%, take only some seconds to completion, and claims too much credit (AFAIK credits are managed by BOINC, not the science app). Something like wrong/insufficious access/directory rights maybe?

Andy

So, if I understood right, quota mechanism leaves BOINC unprotected in case of intentional modification of science app to return bad results marked as success ones?
It could lead to some kind of DoS attack with great network load (new WU could be downloaded at very high rate in such situation).

So, if I understood right, quota mechanism leaves BOINC unprotected in case of intentional modification of science app to return bad results marked as success ones?
It could lead to some kind of DoS attack with great network load (new WU could be downloaded at very high rate in such situation).

I doubt the difference between a quota of 100 and a reduced quota of 1 per day would make much difference to someone designing that sort of DoS attack, they'd need a large number of hosts in either case to make the attack effective.

I just sent a polite PM to the system's owner, though as there are no forum posts listed for the account he probably won't see it.

                                                              Joe

So, if I understood right, quota mechanism leaves BOINC unprotected in case of intentional modification of science app to return bad results marked as success ones?
It could lead to some kind of DoS attack with great network load (new WU could be downloaded at very high rate in such situation).

I doubt the difference between a quota of 100 and a reduced quota of 1 per day would make much difference to someone designing that sort of DoS attack, they'd need a large number of hosts in either case to make the attack effective.

I just sent a polite PM to the system's owner, though as there are no forum posts listed for the account he probably won't see it.

                                                              Joe

But, why would someone turn in faulty results, in the first place.
The credit claimes are all the same and kind off high!
Stupid question maybe, how could one 'proof', f.i. this is fixed?

---