Can we get a bit of an explaination how that is going to work?

---

I to have no idea what this means ?

If its been answered some where else could someone please post a link ?

Cheers

---

It's pretty simple. With the new app, all work units should run for approximately 8 hours by default. The application will figure out how many predictions to make based on this 8 hour limit which can be thought of as a "target cpu run time". You will be able to change this limit as a project specific preference. To do so:

1, click on the "Participants" link above and login if you have to.
2. click on the "View or edit Rosetta@home preferences" link.
3. click on the "Edit Rosetta@home preferences" link.
4. select a "Target CPU run time" from the pull down menu.
5. click the "Update preferences" button.

Cheers for that much appreciated.

So how will this effect the points system ?


Presumably the more predictions a certain computer can make in this eight hour stint means it will pick up more points ?

---

What would be the purpose, advantage or disadvantage, of altering this time parameter?

---

It's pretty simple. With the new app, all work units should run for approximately 8 hours by default. The application will figure out how many predictions to make based on this 8 hour limit which can be thought of as a "target cpu run time". You will be able to change this limit as a project specific preference. To do so:

1, click on the "Participants" link above and login if you have to.
2. click on the "View or edit Rosetta@home preferences" link.
3. click on the "Edit Rosetta@home preferences" link.
4. select a "Target CPU run time" from the pull down menu.
5. click the "Update preferences" button.

How does the app know how many predictions to make within the specified run time?

Is it based on the benchmarks?

---

What would be the purpose, advantage or disadvantage, of altering this time parameter?

My understanding is that this is a method to deal with the bandwidth issue.

If you are on dial-up or a capped high speed connection, then setting the run time high can help decrease the number of down and uploads.

Kathryn

---

Kathryn :o)
The BOINC FAQ Service
The Unofficial BOINC Wiki
The Trac System
More BOINC information than you can shake a stick of RAM at.

Is there then a preferential setting for the science side?

---

The Clangers Forum

BOINC Wiki

The default will be the preferential setting since it will be easier for us to determine the approximate throughput to figure out how many work units to send out. This feature will not effect the crediting system.

Thank you sir.


The Clangers

---

Cheers for clearing that up. :)

---

So basically if we are happy at the moment with our preferences then we should leave well alone ?

many thanks

---

ummm - where does the "science" stand on this? I used to download one unit, run to completion, download another. Is it the case that I could have saved hours of processing time by just killing the unit? What drove this timeout decision? Give us a clue.......

---

This change does not affect the science. Generally, our goal is to predict a large number of protein structures and we can achieve this with both methods. For example, instead of sending out 1,000 work units that make 10 predictions each for a total of 10,000 predictions, we can now determine the average number of predictions per work unit on our new RALPH test server and make an estimate of how many work units to send to clients. So if the average is 20 predictions per work unit on our test server, then we would send out 500 work units to get back roughly 10,000 predictions from our production server. Since we benefit from as much sampling as possible, the more predictions the better. So if 500 work units were not enough, we would just send more to crunch.

... we can now determine the average number of predictions per work unit on our new RALPH test server and make an estimate of how many work units to send to clients.

Since you now seem to pre-run each new WU on RALPH to determine the average number of predictions, you could also determine the average claimed credit per prediction on RALPH, then pass this number to the production server WUs and have them claim that number times the performed predictions as credit (reminds me of the pseudo-rd. discussion we once had around here) ...