0 credits for valid results

A friend posted this host in our forum today :

results.php?hostid=1198913 (not my host)

Those results are most likely valid, it's an incompatibility between CC 4.xx and the current BOINC API lib, that doesn't allow the application to report the runtime to the core client. The results are not affected.

I had the same effect at Einstein with CC4.19 on an old Coppermine 600 running Linux - Einstein does grant credits to such a machine though, ignoring the runtime of 0 seconds.

That is correct.

In the case of a validated quorum of two returned results, the lesser of the two claimed credits is granted. The reason why SETI does this is because they are open source software and anyone can edit the source code to make the science app claim high amounts of credit. Since SETI has a quorum of two and the lesser of the two is granted, this is sort of an anti-cheat measure.

The downside to this is older BOINC clients that do not accurately record their runtime to claim the correct amount of credits. Older BOINC clients used a benchmark * time method of claiming credit, but the credit system has changed after v4.49 to a FLOP-counting system which requires an accurate accounting of time to complete the workunit.

The only solution, if possible, is to upgrade the BOINC client to something newer than BOINC v4.49.
____________

Well, in case of old Linux core clients SETI should probably grant a low, but fixed minimum.

Someone has added some code lines to the API that seem to be thought to restore compatibility to older Linux core clients (using attach_shmem instead of attach_shmem_mmap) - but either it doesn't work or SETI uses an API version that doesn't have this code.


p.s.: On some boxes I couldn't use anything but 4.19 - trouble with the Squid authentication of all cURL BOINC clients back then.

Well, in case of old Linux core clients SETI should probably grant a low, but fixed minimum.

Someone has added some code lines to the API that seem to be thought to restore compatibility to older Linux core clients (using attach_shmem instead of attach_shmem_mmap) - but either it doesn't work or SETI uses an API version that doesn't have this code.

I am aware of all this - but people who use a current CC are affected too, if their partner uses an old core client.

My team mate complained about the validator in our forum, he assumed, that those 0 seconds results were invalid and the validator would still accept them and validate them against his valid ones.

His conclusion has been, that invalid results end up in the science database. Of course I cleared it up in our forum - but others might think the same when they see such a constellation without knowing the history.

I am aware of all this - but people who use a current CC are affected too, if their partner uses an old core client.

My team mate complained about the validator in our forum, he assumed, that those 0 seconds results were invalid and the validator would still accept them and validate them against his valid ones.

His conclusion has been, that invalid results end up in the science database. Of course I cleared it up in our forum - but others might think the same when they see such a constellation without knowing the history.