Look at this host: http://setiathome.berkeley.edu/results.php?hostid=4974846
When it showed as my wingmate with inconclusive I thought it's usual GPU issue (task time of 28 seconds...) but not, it's CPU app.. But quite a strange one.

All tasks I watched are restarted from 100% and have repeating patterns in signals found.

Malice replication of few computed units? Or some issue with host where old checkpoint not deleted from prev task?...

Any opinions?

<core_client_version>6.6.31</core_client_version>
<![CDATA[
<stderr_txt>
Restarted at 100.00 percent.

Flopcounter: 61123513674041.742000

Spike count: 4
Autocorr count: 0
Pulse count: 0
Triplet count: 0
Gaussian count: 2
04:26:09 (8536): called boinc_finish

</stderr_txt>
]]>

---

SETI apps news
We're not gonna fight them. We're gonna transcend them.

Any opinions?

Only that we can only assume from what we see that the stderr is stuck from some prior run. The elapsed and CPU times differ, as do counts from time to time, so something is being launched, but either eororing before initial state can be written, or fully processing and failing to update state. I'd guess either damaged permissions on the slot preventing deletion, and/or a prior state file in the slot. Perhaps the old 6.6.31 client shown there has particular bugs in clearing the slot, or in sanity checks before launch.

---

"Living by the wisdom of computer science doesn't sound so bad after all. And unlike most advice, it's backed up by proofs." -- Algorithms to live by: The computer science of human decisions.