I just took a look at the stats pages and found this one.
P4 3.0 GHz HT

It seems to be a normal P4 3 GHz HT and i´m really wodering how it´s possible for this host to get such a RAC of 2.4K.

Can someone explain that or am i missing something ???

---

Join BOINC United now!

It could be several machines that were merged into one host.

---

There was a thread which explained how you could use one host to download wu's, then take them to other pc's where they were crunched and then return them to the original host to report them back.

This is what I think is going on here.

---

Something odd happening with this host.....have to offset 640 just to see some returned wu's, then only about 50% them returned so far, getting more than 100 wu/day, benchmark results way too high even if oc'd to 4GHz.

Hmmm.....suspect...dare I say it....c$#%ter. Or its a very special cpu!

Live long and crunch!

---

Paul
(S@H1 8888)
And proud of it!

Actually I think both David and rsisto are correct.
The machines account show it as being created today.
Currently that machine has 724 WU's to crunch so he would not be able to finish them all in time. In looking at some of the results that machine has returned I noticed it is using BC 4.19 and SC 4.08. Which I was under the impression that we needed to use at least SC 4.09. I can't remember if SC 4.08 ran the WU's faster?

---

My mistake. There are way way way way way and need I say it again, way more than 724 open WU's for that machine. There are still open WU's at offset 2620 and I quit looking at that point. For anyone who wants to see start here.
http://setiweb.ssl.berkeley.edu/results.php?hostid=940344&offset=720

---

There was a thread which explained how you could use one host to download wu's, then take them to other pc's where they were crunched and then return them to the original host to report them back.

This is what I think is going on here.

So downloading/uploading on a slow machine with low benchmarks, then crunching on a one or more faster PC's? Sounds like cheating to me.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

My mistake. There are way way way way way and need I say it again, way more than 724 open WU's for that machine. There are still open WU's at offset 2620 and I quit looking at that point. For anyone who wants to see start here.
http://setiweb.ssl.berkeley.edu/results.php?hostid=940344&offset=720

It had 4453 WUs issued. The work list still seems to be there, but there's no longer a computer at ID 940344.
Could be one of the Developers testing?

---

There was a thread which explained how you could use one host to download wu's, then take them to other pc's where they were crunched and then return them to the original host to report them back.

This is what I think is going on here.

So downloading/uploading on a slow machine with low benchmarks, then crunching on a one or more faster PC's? Sounds like cheating to me.

Well it all depends what you call cheating. The science work is being done correctly and in time so in this sense it is not cheating. The only way you could consider this cheating is that he is getting an irreal RAC for a host.

One possible explanation could be that he has access to several pc's where he can crunch, but where he does not have internet access, so this could just be the only way to use this pc's.

---

If you ask me setting up a system that claims more credits than WU's are worth is close enough to cheating. The ultimate credits granted will not be incredibly higher than usual but over time, and with more users doing this, this system will push up the claimed credit averages and so the user will get more credits.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...

If you ask me setting up a system that claims more credits than WU's are worth is close enough to cheating. The ultimate credits granted will not be incredibly higher than usual but over time, and with more users doing this, this system will push up the claimed credit averages and so the user will get more credits.

I get what you mean now.

But is the other way round, you have to download in a fast machine (actually report, as the benchmark is used at report time, where simplifying: benchmark * time = credit) and then crunch in a slow machine so to have high processing times, this way you maximize credits as you have both high benchmarks and high processing times.

But looking at his results, the credit requests seem to be OK. (http://setiweb.ssl.berkeley.edu/results.php?hostid=940344&offset=2780)

---

Ah yes...My bad.

---

Kolch - Crunching for the BOINC@Australia team since July 2004.
Search for your own intelligence...