question, why can't someone take work unit "a" from machine "a" and put into into machine "b" and have machine "b" crunch that work unit and report it...

answer, because it's assigned to a machine...

question, why is it assigned to a machine and not an end user....

---

question, why can't someone take work unit "a" from machine "a" and put into into machine "b" and have machine "b" crunch that work unit and report it...

answer, because it's assigned to a machine...

question, why is it assigned to a machine and not an end user....

It can be done, but you have to grab the whole folder. I install BOINC in a way so it is E:\BOINC and E:\BOINC\DATA When I had some SP goto some REALLY show machines I just grabbed that folder from the slower machine. renamed the folder on the faster ones to E:\BOINC.<machinename>\ then ran the manager and processed the wu on the faster one with network comms off. Then dropped the folder back on the slow machine and let it upload it.

But I know what you are saying. In the old days it was easy to have 1 machine download wu's and just transfer the wu to another machine that didn't have internet access.

---

SETI@home classic workunits: 93,865 CPU time: 863,447 hours
Join the [url=http://tinyurl.com/8y46zvu]BP6/VP6 User Group[

question, why can't someone take work unit "a" from machine "a" and put into into machine "b" and have machine "b" crunch that work unit and report it...

To prevent cheating

question, why is it assigned to a machine and not an end user....

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine. It is entirely possible for someone to have 50 machines crunching, but have only a single machine upload and report, thus artificially inflating that machine's standings in the ranks that some users focus on so much (so much so that cheating has been known to happen).

---

question, why can't someone take work unit "a" from machine "a" and put into into machine "b" and have machine "b" crunch that work unit and report it...

answer, because it's assigned to a machine...

question, why is it assigned to a machine and not an end user....

Wow there are a lot of reasons... When Boinc first started there was an issue with work getting lost when a power outage hit a machine. So they went to work and fixed that. A Portion of the fix was to insure all information about the workunit "a" was properly written somewhere. When Your Computer after contacting the Scheduler request "work" it gets handed off to the Download Server for workunit "a" as the download occurs information is written into the client_state.xml file in the Boinc folder. It looks something like this.

<file_info>
<name>ap_08ja09ab_B1_P1_00008_20090615_30497.wu_3_0</name>
<nbytes>13421.000000</nbytes>
<max_nbytes>655360.000000</max_nbytes>
<md5_cksum>2b61898e64f039fc169806de9a513a1a</md5_cksum>
<generated_locally/>
<status>1</status>
<upload_when_present/>
<url>http://setiboincdata.ssl.berkeley.edu/beta_cgi/file_upload_handler</url>
<persistent_file_xfer>
<num_retries>15</num_retries>
<first_request_time>1247606421.421875</first_request_time>
<next_request_time>1247672283.063047</next_request_time>
<time_so_far>33.046875</time_so_far>
<last_bytes_xferred>0.000000</last_bytes_xferred>
</persistent_file_xfer>
<signed_xml>
<name>ap_08ja09ab_B1_P1_00008_20090615_30497.wu_3_0</name>
<generated_locally/>
<upload_when_present/>
<max_nbytes>655360</max_nbytes>
<url>http://setiboincdata.ssl.berkeley.edu/beta_cgi/file_upload_handler</url>
</signed_xml>
<xml_signature>
a170736de264e75e5a076b26d7a2f085c2ead05cabc646ad154341f94bacb6ee
5c6103b8ce52dbc4dbdada5b6d97289707650b95c009fc281568df178bd1a76e
5ca6be00b768787264e11121ffb2f69ee7e0488de9237b34efa80d85466eda63
643eb4aa83ff2fa1f87add3751188372e1b8b6a16146bffdb2a7b71657dba11d
.
</xml_signature>
</file_info>

So if you carry workunit "a" to another computer there is no way to just drop it into the projects folder and start boinc. Boinc has no idea of what the file is or what to do with it.

The other portion is as the computer starts to work on file "a" it also writes information in the "scheduler reply" file in the Boinc folder. As the file gets uploaded and is ready to report that information get sent to the Scheduler so that the Scheduler knows how much work to send.


Does that help?

Regards

---

Please consider a Donation to the Seti Project.

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine. It is entirely possible for someone to have 50 machines crunching, but have only a single machine upload and report, thus artificially inflating that machine's standings in the ranks that some users focus on so much (so much so that cheating has been known to happen).


It that how some of these people are processing about a 45ish work unit in about 100 seconds? I've seen a bunch of people like that and wonder what they did to their systems to optimize it.

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine. It is entirely possible for someone to have 50 machines crunching, but have only a single machine upload and report, thus artificially inflating that machine's standings in the ranks that some users focus on so much (so much so that cheating has been known to happen).


It that how some of these people are processing about a 45ish work unit in about 100 seconds? I've seen a bunch of people like that and wonder what they did to their systems to optimize it.

The 100sec results are being processed on CUDA grahics cards.

The actually take more than 100sec of 'wall time', but only the time the CPU spends is reported. The 10-30min of GPU time is not being reported.

So no one is getting through work units in 100sec, although some are trying to get close to it.

Ian

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine.

You're right, that is the default credit scheme built into BOINC, and what you'll get if you run your own project server straight out of the box.

But SETI, and many other projects, have evolved away from that default scheme over the years. Here, time isn't taken into account at all when calculating credit.

In Classic, there were a fairly large number of cheats possible. One of the favorites was to crunch a task with one computer until there were only a few seconds left. Then replicate that crunched task to a bunch of other computers, let them finish crunching, and everyone reports the results. This one cheat is responsible for the strict assignment of tasks to one BOINC installation. It is possible to move the entire BOINC installation from one machine to another, but it is NOT possible to move tasks from one place to another. The server is going to ignore the report of a task from a BOINC installation to which the task was not originally assigned.

---

BOINC WIKI

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine.

You're right, that is the default credit scheme built into BOINC, and what you'll get if you run your own project server straight out of the box.

But SETI, and many other projects, have evolved away from that default scheme over the years. Here, time isn't taken into account at all when calculating credit.

Last time I said that, I was corrected by other members of the community letting me know that Eric's script still works from the benchmark, so indirectly the benchmark is still involved in the credit granting formula.

---

Credit is granted based upon a formula that involves the benchmark scores BOINC runs on a machine.

You're right, that is the default credit scheme built into BOINC, and what you'll get if you run your own project server straight out of the box.

But SETI, and many other projects, have evolved away from that default scheme over the years. Here, time isn't taken into account at all when calculating credit.

Last time I said that, I was corrected by other members of the community letting me know that Eric's script still works from the benchmark, so indirectly the benchmark is still involved in the credit granting formula.

Fair enough, you're absolutely right - and I was probably one of the people who said it!

But Eric's script works by slowly averaging (over 30 days) a rate of credit that is applied to all tasks and all hosts.

The original post, from which I only quoted the first sentence, was in the context of cheating. Under the old, default benchmark*time credit scheme, fiddling with the benchmarks of a single host could possibly gain a cheater some benefit - as has recently been graphically illustrated at AQUA. With flopcounter reporting, it would require a concerted effort by a high proportion of users to game the system: when he introduced it, Eric reckoned that it wouldn't be affected by all the Lunatics, and all the users of optimised applications of all varieties, added together.

But I do wonder if CUDA is big enough to swing it.

But Eric's script works by slowly averaging (over 30 days) a rate of credit that is applied to all tasks and all hosts.

Isn't that script this one?

---