True. Maybe he gets credit without actually crunching the WUs?
No way the box is really that fast. It benchmarks like my Core Duo and that took more than 40 hours for that kind of WU. I'd believe if it was 29 hours, but not 29 seconds. This is either a bug or sth deliberate.
Looking at his results page, the previous time he reported to E@H was 17 Sep 2007. That gives approx. 7 days he could have been crunching all these WUs. SOMETHING is definitely FUBAR'd on either his end or the download server.
The debugging output of those "instant"crunching" results definitely look ok and regular, you can also deduce the real-time it took to produce this output.
I suspect that the "Result sent at" timestamp is not authentic. There is no way this debugging output could have been produced by a "regular" einstein app in the time between "result sent" and "result reported " timestamps. it would be informative to look up the events in the scheduler log.
If the timestamps are authentic, then this result must have been crunched before the "result sent" timestamp. E.g. result was sent, crunched, re-sent another time, reported immediately (as it was already finished). The CPU seconds value should still be the real, higher one, but maybe there's a BOINC sanity check that truncates the CPU time to the duration between download of the result and its reporting.
So maybe even a scheduler problem (resending stuff the client already has ??? )...
Cheating is unlikely as I don't see that many result reported after all, so nothing gained.
Sounds like the most logical explanation we've had so far. But why do results get re-sent if they are already crunched? Maybe it really is a scheduler problem. Or maybe it has something to do with restoring the Einstein folder from a backup?
The debugging output of those "instant"crunching" results definitely look ok and regular, you can also deduce the real-time it took to produce this output.
I suspect that the "Result sent at" timestamp is not authentic. There is no way this debugging output could have been produced by a "regular" einstein app in the time between "result sent" and "result reported " timestamps. it would be informative to look up the events in the scheduler log.
If the timestamps are authentic, then this result must have been crunched before the "result sent" timestamp. E.g. result was sent, crunched, re-sent another time, reported immediately (as it was already finished). The CPU seconds value should still be the real, higher one, but maybe there's a BOINC sanity check that truncates the CPU time to the duration between download of the result and its reporting.
So maybe even a scheduler problem (resending stuff the client already has ??? )...
Cheating is unlikely as I don't see that many result reported after all, so nothing gained.
CU
H-BE
I still have a hard time believing that his computer could have crunched all those units in the time allotted. That is, (by my count) his computer reported 12 units on Sept 24. Two of those looked "normal" and reported times of about 100 hours each. Those two units were sent to his computer on Sept 9 or 15 days prior to reporting. Fifteen days equals 360 hours of time. If his computer spent 200 of those hours crunching the "normal units", that leaves only 160 hours for crunching the other 10 "suspect" units. I don't think so! But, please, somebody check my math and logic.
EDIT: His Computers belonging to lists 4 computers, all of which contacted the server on Sept 24, but only 1 shows recent results. Could he have crunched the "suspect" units on the other computers and reported them on the active one? I don't know why he would want to do that but it might account for the total amount of time needed.
I still have a hard time believing that his computer could have crunched all those units in the time allotted. That is, (by my count) his computer reported 12 units on Sept 24. Two of those looked "normal" and reported times of about 100 hours each. Those two units were sent to his computer on Sept 9 or 15 days prior to reporting. Fifteen days equals 360 hours of time. If his computer spent 200 of those hours crunching the "normal units", that leaves only 160 hours for crunching the other 10 "suspect" units. I don't think so! But, please, somebody check my math and logic.
EDIT: His Computers belonging to lists 4 computers, all of which contacted the server on Sept 24, but only 1 shows recent results. Could he have crunched the "suspect" units on the other computers and reported them on the active one? I don't know why he would want to do that but it might account for the total amount of time needed.
I think you hit the nail on the head here: The computer in question is a Pentium D, with 2 cores, at > 3 GHz, and should be able to crunch a monster faster than the 100 hours!! I think what we see here is the effect of a computer upgrade. The "instant" units were crunched on the Pentium D and the regular ones on an older model. The dard-disk with the BOINC installation was transplanted and this might have messed up the whole flow.
Does this make sense?
The debug output indicates a real-time crunching time of approx 170000 seconds, multiplied times 2 cores this would allow for the number of "instant" units submitted.
RE: True. Maybe he gets
)
Looking at his results page, the previous time he reported to E@H was 17 Sep 2007. That gives approx. 7 days he could have been crunching all these WUs. SOMETHING is definitely FUBAR'd on either his end or the download server.
Seti Classic Final Total: 11446 WU.
RE: Probably just
)
This is not my work and not my computer.
Probably a validation problem.
RE: RE: Probably just
)
Akos,
That was a joke. (But, admittedly, a bad one.)
Stick
Look at his other times,
)
Look at his other times, 364,300 , 363,613 & 140's and 260's all taken together NONE make any sense.
e6600 quad @ 2.5ghz
2418 floating point
5227 integer
e6750 dual @ 3.71ghz
3657 floating point
8105 integer
RE: Look at his other
)
Yeah, that's all very weird. Looks like something that Bernd and Bruce should investigate.
The debugging output of those
)
The debugging output of those "instant"crunching" results definitely look ok and regular, you can also deduce the real-time it took to produce this output.
I suspect that the "Result sent at" timestamp is not authentic. There is no way this debugging output could have been produced by a "regular" einstein app in the time between "result sent" and "result reported " timestamps. it would be informative to look up the events in the scheduler log.
If the timestamps are authentic, then this result must have been crunched before the "result sent" timestamp. E.g. result was sent, crunched, re-sent another time, reported immediately (as it was already finished). The CPU seconds value should still be the real, higher one, but maybe there's a BOINC sanity check that truncates the CPU time to the duration between download of the result and its reporting.
So maybe even a scheduler problem (resending stuff the client already has ??? )...
Cheating is unlikely as I don't see that many result reported after all, so nothing gained.
CU
H-BE
Sounds like the most logical
)
Sounds like the most logical explanation we've had so far. But why do results get re-sent if they are already crunched? Maybe it really is a scheduler problem. Or maybe it has something to do with restoring the Einstein folder from a backup?
That sounds plausible as
)
That sounds plausible as well. Something that brings client and server out of sync and messes everything up.
CU
H-B
RE: The debugging output of
)
I still have a hard time believing that his computer could have crunched all those units in the time allotted. That is, (by my count) his computer reported 12 units on Sept 24. Two of those looked "normal" and reported times of about 100 hours each. Those two units were sent to his computer on Sept 9 or 15 days prior to reporting. Fifteen days equals 360 hours of time. If his computer spent 200 of those hours crunching the "normal units", that leaves only 160 hours for crunching the other 10 "suspect" units. I don't think so! But, please, somebody check my math and logic.
EDIT: His Computers belonging to lists 4 computers, all of which contacted the server on Sept 24, but only 1 shows recent results. Could he have crunched the "suspect" units on the other computers and reported them on the active one? I don't know why he would want to do that but it might account for the total amount of time needed.
RE: I still have a hard
)
I think you hit the nail on the head here: The computer in question is a Pentium D, with 2 cores, at > 3 GHz, and should be able to crunch a monster faster than the 100 hours!! I think what we see here is the effect of a computer upgrade. The "instant" units were crunched on the Pentium D and the regular ones on an older model. The dard-disk with the BOINC installation was transplanted and this might have messed up the whole flow.
Does this make sense?
The debug output indicates a real-time crunching time of approx 170000 seconds, multiplied times 2 cores this would allow for the number of "instant" units submitted.
CU
H-B