How can anyone have a valid result with ZERO processor time??????

application SETI@home Enhanced
created 3 Nov 2008 10:02:16 UTC
name 13oc08ab.7667.115789.15.8.118
canonical result 1044512151
granted credit 0.00
minimum quorum 2
initial replication 2
max # of error/total/success tasks 5, 10, 5
Task ID
click for details Computer Sent Time reported
or deadline
explain Server state
explain Outcome
explain Client state
explain CPU time (sec) claimed credit granted credit
1044512151 3361574 3 Nov 2008 10:02:47 UTC 4 Nov 2008 12:45:14 UTC Over Success Done 18,909.98 25.55 0.00
1044512152 3519732 3 Nov 2008 10:02:47 UTC 3 Nov 2008 14:12:41 UTC Over Success Done 0.00 --- 0.00

By running an extremely ancient version of BOINC - v4.19 - which doesn't report the true processor time properly.

He/she/it has other problems as well:

SETI@home error -3 Can't write to file -- disk full?
in checkpoint()
File: seti.cpp
Line: 557

- generally not an example of a well-maintained system.

So does my machine get penalized for being paired with a machine that is using out of date BOINC software???

So does my machine get penalized for being paired with a machine that is using out of date BOINC software???

Yes - it happens to all of us from time to time.

Story of my life...SOSDD

That's happened to me a few times. I had a MB WU last week that was supposed to give me ~45 credits. My wingman claimed 22, and it was also sent out to a third party. Third party claimed 0.07 credits, and that's what all three of us were given.

Still waiting for two ~350 credit AP WUs to be validated by third party since I'm currently being granted 0 for those.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

Sorry, it seems one of my machines also sent back a 0.07 credit result.

358500045

However, my apps are up to date. So it cannot be blamed on old apps.

Details of my last startup

04/11/2008 8:07:01 AM||Starting BOINC client version 5.10.45 for windows_intelx86
04/11/2008 8:07:01 AM||log flags: task, file_xfer, sched_ops
04/11/2008 8:07:01 AM||Libraries: libcurl/7.18.0 OpenSSL/0.9.8e zlib/1.2.3
04/11/2008 8:07:01 AM||Executing as a daemon
04/11/2008 8:07:01 AM||Data directory: C:\Program Files\BOINC
04/11/2008 8:07:01 AM||BOINC is running as a service and as a non-system user.
04/11/2008 8:07:01 AM||No application graphics will be available.
04/11/2008 8:07:01 AM|SETI@home|Found app_info.xml; using anonymous platform
04/11/2008 8:07:01 AM||Processor: 2 GenuineIntel Intel(R) Core(TM)2 CPU T5500 @ 1.66GHz [x86 Family 6 Model 15 Stepping 6]
04/11/2008 8:07:01 AM||Processor features: fpu tsc pae nx sse sse2 pni mmx
04/11/2008 8:07:01 AM||OS: Microsoft Windows Vista: Home Edition, Service Pack 1, (06.00.6001.00)
04/11/2008 8:07:01 AM||Memory: 1.99 GB physical, 4.21 GB virtual
04/11/2008 8:07:01 AM||Disk: 52.14 GB total, 13.06 GB free
04/11/2008 8:07:01 AM||Local time is UTC -7 hours

Sorry, it seems one of my machines also sent back a 0.07 credit result.

358500045

However, my apps are up to date. So it cannot be blamed on old apps.

Don't worry about that one. It has a standard message:

SETI@Home Informational message -9 result_overflow
NOTE: The number of results detected exceeds the storage space allocated.

which indicates that it exited in a controlled fashion because of the nature of the data in the WU. You'll probably find that your wingman reports exactly the same thing.

The problem that people are reporting here arises when old apps don't report the same as the current ones.

That's happened to me a few times. I had a MB WU last week that was supposed to give me ~45 credits. My wingman claimed 22, and it was also sent out to a third party. Third party claimed 0.07 credits, and that's what all three of us were given.

Still waiting for two ~350 credit AP WUs to be validated by third party since I'm currently being granted 0 for those.

If all three got credit, shouldn't it have been the 22 that was granted? I thought in the case of three results, the lowest and highest were thrown out?

-Dave

---

If all three got credit, shouldn't it have been the 22 that was granted? I thought in the case of three results, the lowest and highest were thrown out?

May have been. I just remember there were three radically different claims and I got shafted.

---

Linux laptop:
record uptime: 1511d 20h 19m (ended due to the power brick giving-up)

By running an extremely ancient version of BOINC - v4.19 - which doesn't report the true processor time properly.

He/she/it has other problems as well:

SETI@home error -3 Can't write to file -- disk full?
in checkpoint()
File: seti.cpp
Line: 557

- generally not an example of a well-maintained system.

It also requires one of a few OS's that don't properly do CPU time accounting, notably 95/98/me.

---

BOINC WIKI

By running an extremely ancient version of BOINC - v4.19 - which doesn't report the true processor time properly.
...

It also requires one of a few OS's that don't properly do CPU time accounting, notably 95/98/me.

At least half the hosts identified as reporting zero CPU time with BOINC 4.x in the Claimed credit zero thread were Macintosh, none were Win95/98/me.

Win9x systems truly do not waste processor power keeping track of every finicky detail anyone might ever want to know, but Microsoft has a free utility called WinTop which will provide CPU time. The necessary code to use the wintop vxd was discussed in 2001 on the newsgroups related to S@H. At that time it would have made sense to add the capability to S@H from where it would have migrated to BOINC. Too late now.

                                                                Joe