Definitely an overclocking problem. My wife's computer http://setiathome.berkeley.edu/show_host_detail.php?hostid=1228066has the same setup, and his floating points and integers are like twice that of her's.

I just added up the CPU seconds reported for this system on units sent 28 July and returned 4 Aug ONLY. I did not include the units sent 25-26-27 July and returned 4-7 Aug (out of order) for which some work may have been done in this time, so this number may be low... It could possibly be totally wrong as well, as I just 10-keyed this into a calculator, this is not a rigorous scientific analysis, so buyer beware;

I get 1,570,216.62 CPU seconds. That's 26,170.27 CPU minutes, or 436.17 CPU hours, or 18.17 CPU days.
Now a 3GHz P4 is pretty quick, but I don't see how it can do 18 CPU days of work (or more) in 8 calendar days, unless it has at least 3 CPUs. (Says it has 2.) Being a Mac person, I know nothing about Intel hardware (yet...)

No accusation of cheating from me, I simply don't know enough (or care, the results are being validated, and that's what ultimately matters), but given the thousands of errored WUs and the thousands of WUs "in progress", and the fact that results are coming in for 'later' units before the results for 'earlier' units, and the discrepancy in "CPU time" and "clock time", I do feel someone needs to look into what is going on with this system...

I second that investigation idea.

So this guy is the reason we need 5 computers to split the work units and we have run out of disk space!

Nahh... This guy is just a drop in the bucket... Now, if there were several hundred to a few thousand of him... Then it would matter.

How in the world did he get 2 million credits? (I'm too lazy to do the math, but it seems a bit high.)

Yes, you are correct. This figure seems quite a bit too much too high.

2,331,409.18 credits. Now, using the OLD average credits per result of 37, this gives 63011 results. Seeing his userID number (522) he was part of the BOINC Beta project, but no credit was brought forward into the production BOINC Seti project. So, since the BOINC Seti project has been 'live' for about 13 months (at 30 days per month), that gives that machine about 161 results per day (or about 80 results per day per 'cpu' (intel P4 3.00, shows as 2 cpus on the computer record), *IF* it has been crunching since day one of the project. So, yeah... Something is fishy about it.

Maybe command central should investigate and change some algorithm somewhere so that such wu-blackholes don't occur again.

Yes, this needs to be looked at, however if the functionality were TOTALLY removed, this would remove a method that users have to get back into full production after having fixed a problem on their computers. Perhaps limiting the number of times one can do this per time period.....

I would not worry about it being a result-'black hole', however. As much as this looks like, it really only is a drop in the bucket (several hundred results) when compared to the total number of results processed daily by BOINC/Seti. Remember, all these results (his errors or potiential overdues) have been or will be reissued to other participants. None (in this case, unlike the v4.13 case) will be lost.

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

Pretty impressive! (and good sleuthing, too!)

So this guy is the reason we need 5 computers to split the work units and we have run out of disk space!

How in the world did he get 2 million credits? (I'm too lazy to do the math, but it seems a bit high.)

Maybe command central should investigate and change some algorithm somewhere so that such wu-blackholes don't occur again.

---

May this Farce be with You

I found the 'current' system ID.

http://setiathome.berkeley.edu/show_host_detail.php?hostid=1262723

Belongs to

http://setiathome.berkeley.edu/show_user.php?userid=552

That computer has about 1235 work units either errored out or 'in progress'(about half errored out, the other half 'in progress') since the last 'good' result was turned in back on July 28th.

http://setiathome.berkeley.edu/results.php?hostid=1262723&offset=1220

My 'giving him the benefit of the doubt' guess would be that he has either hardware (overclock?) problems or has had his boinc install corrupted. It looks like he has been hitting either the 100 results per cpu per day limit or the reduced quota for turning in errors, and has been detatching/reattaching the client to get new ones (hence the hostid being different every day).

A typical stdout is:

<core_client_version>4.19</core_client_version>
<message>Funzione non corretta. (0x1) - exit code 1 (0x1)
</message>
<active_task_state>1</active_task_state>
<signal>0</signal>

This one is 4.19, but i did see a few on 4.45 (near the start of the errors). A possibility is that he made a mistake on an upgrade from 4.19 to 4.45. I would suggest that he uninstall BOINC totally (wipeing out the directory structure), then reinstall it. That, and reset his computer to stock speed, if he is overclocking.

---

https://youtu.be/iY57ErBkFFE

#Texit

Don't blame me, I voted for Johnson(L) in 2016.

Truth is dangerous... especially when it challenges those in power.

I always look at my stats (that is: BOINCstats) to check for errors, and I have watched the number 1 host in SETI for a couple of days now. The number 1 is a new system every day (another ID) with just a bit more credit, but the same specifications.

Today that system has id 1261329 but when checked (here it has already zero credits, so it probably moved to a new ID again.

What is happening here?

---

Join team BOINCstats