I just looked at one of my results and I generally compare my CPU time to others that are running the same WU.
I looked at a one and my CPU seconds were what they usually are but one other running the same WU had ~.5 seconds, yes, a half a second for 40 some credits.
So, I looked at his computer and his other results and they ALL less than a second.
Is that possible???
http://setiathome.berkeley.edu/show_host_detail.php?hostid=3232000

---

Looking at that host, you also see:

Measured floating point speed 42769575.08 million ops/sec
Measured integer speed 2453.28 million ops/sec

And all of his results show as valid. Kinda fishy.

---

Looking at that host, you also see:

Measured floating point speed 42769575.08 million ops/sec
Measured integer speed 2453.28 million ops/sec

And all of his results show as valid. Kinda fishy.

I noticed that too on the floating point speed, is that even possible.
Fishy wasn't exactly what I was thinking though, lol.

I took one of his results which was .59 sec for a credit of 48.36 - that would equal 81.97 credits for every "second" - so 60 seconds in a minute time 60 minutes in an hour time 24 hours in a day times 81.97 = 86,400 credits a day. Not bad, lol.

I think we found E.T. and he brought his computer, lol.

---

This kind of speed discrepancy has been seen before on Linux systems in the past. Generally it was found to happen because the BOINC client and the Linux OS do not keep a proper track of the time taken.

And the high Floating point is probably because the owner is using a self complied BOINC client for the Linux system.

---

We've seen this kind of thing before. Most likely just due to a 'home rolled' Linux build.

Don't recall what the penguins who hang here said the usual reason for it is. It's been awhile since it came up last. Obviously the CC isn't correctly recording the true CPU time. If you look over the results, the timings between reports is what you'd expect for a machine in this class.

So screwy looking? Yes. Cause for concern? Not really.

Alinator

This kind of speed discrepancy has been seen before on Linux systems in the past. Generally it was found to happen because the BOINC client and the Linux OS do not keep a proper track of the time taken.

And the high Floating point is probably because the owner is using a self complied BOINC client for the Linux system.

That makes sense because his average turnaround time is almost 2 days. If he was really returning the WU’s in seconds, his average turn-around time would be 0.01 days or something.

This kind of speed discrepancy has been seen before on Linux systems in the past. Generally it was found to happen because the BOINC client and the Linux OS do not keep a proper track of the time taken.

And the high Floating point is probably because the owner is using a self complied BOINC client for the Linux system.

That makes sense because his average turnaround time is almost 2 days. If he was really returning the WU’s in seconds, his average turn-around time would be 0.01 days or something.

You're probably right.

I noticed something else that doesn't appear to make sense. The computer joined on 4-2-07 (21 days ago) but has 129,293 credits which is 6,156 credits per day but his RAC is 145. Any thoughts? I may not be looking at this incorrectly.

---

Merged with another host ID?

Alinator

Merged with another host ID?

Alinator

I see said the blind man.

Ah, didn't think of that.

---

More weirdness here.

This guys computers are just creating hundreds of Compute Errors using <core_client_version>3.20</core_client_version>!

What a waste of time, energy and resources! I know they all get re-issued to another client, but "William H. Green IV" and his 96 computers have not received any credit since Sep 2005.

---

Sir Arthur C Clarke 1917-2008

Lol, every single one a zombie! prolly network installed just for the screensaver and forgotten about.

---

"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.

I tested a wu on my works brand new simulation computer a couple of days ago and came up with one in 25.625 seconds for a 62WU. If he was faster he needed a Cray XT4 or the Blue Genie computer.

More weirdness here.

This guys computers are just creating hundreds of Compute Errors using <core_client_version>3.20</core_client_version>!

What a waste of time, energy and resources! I know they all get re-issued to another client, but "William H. Green IV" and his 96 computers have not received any credit since Sep 2005.

LOL...

Well I certainly think we can all agree, 3x clients should without a doubt be cut off! :-)

At this point we need every single result we can get for hosts which actually have a chance of returning it.

@ Jason:

And must make for a pretty dull screensaver at that! :-)

Alinator

PS: I could have sworn that I saw (maybe back when Classic shutdown) you were going to have to run 4x at that point. Just don't remember for sure now.

More weirdness here.

This guys computers are just creating hundreds of Compute Errors using <core_client_version>3.20</core_client_version>!

What a waste of time, energy and resources! I know they all get re-issued to another client, but "William H. Green IV" and his 96 computers have not received any credit since Sep 2005.

IMO, that's one computer with 96 host IDs; they each have identical specs. All except the most recent one have a daily quota of 1 WU and haven't downloaded any work.

Looks to me like the owner does a detach & reattach every now and then trying to get things working.

                                                                  Joe

One other theory to consider: Maybe someone, something or the project “Pi**** him off” somehow, and this is his way of getting even.

That’s an awful lot of computers to NOT be aware your doing “aBsOlUtElY” nothing!

I guess THIS cant be right either.... can it?

http://setiathome.berkeley.edu/result.php?resultid=524714966

speed: -798887322 MHz -- read MB/s: L1=-2147483648, L2=-2147483648, RAM=-2147483648

Work Unit Info
True angle range: 0.477710

Spikes Pulses Triplets Gaussians Flops
0 2 1 1 14843904411866

Guess i have to do some "hardcore reverse" oc´ing to fix it :)

Regards