On viewing my results, I noticed another SETI user returned a value of 0.00 CPU time and claimed a credit of 0.00.
Another user claimed 240.19 seconds of CPU time and credit of 0.29.

I ended up in the middle with a CPU usage of 56.84 seconds and claimed a credit of 0.18.

Therefore, this cock-eyed system granted the first user a credit of 0.18 for no actual work, whilst denying the last user better credit that may have occured if a 4th users figures had been incorporated and the whole thing averaged.

If this is possible with this software, perhaps half of us should throw in the towel, do no SETI work at all on our computers and let the rest do the work for us whilst we gain the credit?

I still have the ID of the "miscreant" if anybody is interested, provided the results are not wiped from the system at the end of the month as occurred at the end of March.

---

Some computers don't record a time if it less than a certain number of seconds run. The same miniscule little bit of work was still done so credit was granted.

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

> On viewing my results, I noticed another SETI user returned a value of 0.00
> CPU time and claimed a credit of 0.00.
> Another user claimed 240.19 seconds of CPU time and credit of 0.29.
>
> I ended up in the middle with a CPU usage of 56.84 seconds and claimed a
> credit of 0.18.
>

There have been some bugs in how BOINC keeps track of cpu-time, there end-time is reported as cpu-time at last checkpoint before end. Since this wu was "noisy" and therefore terminated very early, the last checkpoint for one of the crunchers was at zero cpu-time.

In seti most wu isn't "noisy", so an ocassional zero-granted 1-minute-wu isn't really a problem. In other projects like LHC on the other hand it has been a much bigger problem.

Anyway, bug-fix will be included in next seti-application.


BTW, only results passing validation gets any credit, and the validator doesn't care whatever claimed credit a result has till after results validated. So it's not anyone not crunching the wu correctly, but a bug with reporting correct cpu-time.

In response to Steve Cressman's comment:
The computer that returned the zero value was a Pentium Mobile at 1500MHz. I run an AMD 3200+XP. He might have run a close second to me at 57 seconds but there is no way that he could have crunched that result in no time at all.

The bug problem sounds like the best answer.

I don't mind if there is such a problem, as long as the software is not open to "crooks" capable of manipulating their results.

---

I wasn't reporting a bug , I was responding to the original question and telling him that some computers won't record a time if the WU does not run long enough.......

---

98SE XP2500+ @ 2.1 GHz Boinc v5.8.8

And God said"Let there be light."But then the program crashed because he was trying to access the 'light' property of a NULL universe pointer.

> In response to Steve Cressman's comment:
> The computer that returned the zero value was a Pentium Mobile at 1500MHz. I
> run an AMD 3200+XP. He might have run a close second to me at 57 seconds but
> there is no way that he could have crunched that result in no time at all.
>
> The bug problem sounds like the best answer.
>
> I don't mind if there is such a problem, as long as the software is not open
> to "crooks" capable of manipulating their results.
>
I have seen this frequently with the noisy workunits. Personally I don't get upset with credit awards in the hundredths.

I have not seen this happen with "normal" workunits.

I was not intending this to become a saga..........

If a result is reported before a particular machine has "updated it's time", that's one thing.
But strictly speaking, the result should not count when it is "validated". It is not logically possible to process a unit in zero time and therefore this result should have been rejected.
The work unit was not so small that it could be processed in milliseconds, as my result proves.

I am not arguing over credit for small units, but merely asking if this was a genuine return or a "smart guy with a modified piece of software" I know that it is possible to fiddle the benchmark programming to make a PC return a higher result for the Dhrystone result.

---

I guess that I must now add myself to the list of "suspects" ...........

The very same thing has happened to me - it would appear that on 30 April 2005 my machine reported a work unit with a time of zero and claimed a credit of zero, for which I was was granted credit of 0.43.

Swings and roundabouts at the moment then.

---