This new feature allows a user to set a target cpu run time as a project specific preference. In order to set this feature, you must:

1. login.
2. click on the "Participants" link on the main page to view your account settings.
3. click on "View or edit RALPH@home preferences."
4. click on "Edit RALPH@home preferences."
5. select a "Target CPU run time" from the pull down menu.
6. click the "update preferences" button.

Setting this feature should make all work units run for approximately the selected amount of CPU time. This option will allow you to decrease your bandwidth usage per work unit and also keep a consistent run time for all work units. The accuracy of actual CPU run times with this setting should be +/- the CPU run time average per predicted structure.

---

Uhm.. ok.. first :) I just got here.. but I'm also not a -complete- idiot..

However, I must now seem like one, because I was hoping you could explain this in much more detail, and explain some of the effects of doing such with various workunits, and what we should expect credit-wise, science-wise.. etc..

---

looks like it is working as it should, for my first WU at least. :)
only missed the target cpu time by 5 minutes.

Uhm.. ok.. first :) I just got here.. but I'm also not a -complete- idiot..

However, I must now seem like one, because I was hoping you could explain this in much more detail, and explain some of the effects of doing such with various workunits, and what we should expect credit-wise, science-wise.. etc..

basically it tries to find more matches per workunit than it would normally, so instead of downloading 10 workunits and getting 10 "answers" for each, you can tell it to download 5 and work out 20 "answers" for each, the project gets the same amount of science done, but it costs you less bandwidth

as for credit, i'd assume that the general way of boinc will continue, the longer work takes to do, the more credit you get, think of it in terms of "credit per structure result"

you'll be producing the same number of "answers/results" but more of those answers will be for the same workunit

I have a question:

for those of us (including myself) who don't have bandwidth issues, what is the recommendation, currently i have my prefs set to "not selected", but does this mean no option is applied, or will the scheduler know that i'm willing to accept anything?

if a value has to be selected, what is the "normal" one used on the main rosetta project?

It's completely up to you. The "not selected" would use a work unit specific value. The default is 1 hour on the test server and will be 8 hours on R@h, however, it may change depending on the work unit and the type of test. The only way to ensure a consistent value is to set the preference.

---

It's completely up to you. The "not selected" would use a work unit specific value. The default is 1 hour on the test server and will be 8 hours on R@h, however, it may change depending on the work unit and the type of test. The only way to ensure a consistent value is to set the preference.

Why not just work out 99 predictions no matter what?

---

We are going to update the code to remove the 99 limit. For most work units 99 would take too long. We would prefer lower run times so that results are returned quicker.

---

We are going to update the code to remove the 99 limit. For most work units 99 would take too long. We would prefer lower run times so that results are returned quicker.

Well, the only problem I am seeing with this, is the accurracy of the 1 hour workunits, versus the 8 hour workunits.

Surely this isn't my issue as a LOWLY tester :) , but it helps to understand the under-workings of it all. Here's how I currently understand it :

Workunit [insert workunit name].001 gets sent out to (hypothetically) 5 people.

User 1 processes it for an hour, and returns 6 structures.
User 2 processes it for 2 hours, and returns 15 structures.
User 3 goes for 4 hours and returns 45 structures.
User 4 does the full 8 hours, and returns the max of 99 structures, but ends early at 7 hours 30 minutes.

(again, hypothetical figures)
#1 claims 60 credit
#2 claims 120 credit
#3 claims 480 credit
#4 claims 900 credit

so... then you've got 4 seperate results for 1 workunit? How is credit canonical for User #3, or 4?

Assuming even if selecting your processing time preference will limit you to workunits that are only sent to like-setting machines, (I.E. once a workunit gets tagged as 4 hour processing times, only people with this preference can d/l them.. etc) Then at what point does the extra time become redundant?

---

We are going to update the code to remove the 99 limit. For most work units 99 would take too long. We would prefer lower run times so that results are returned quicker.

Well, the only problem I am seeing with this, is the accurracy of the 1 hour workunits, versus the 8 hour workunits.

Surely this isn't my issue as a LOWLY tester :) , but it helps to understand the under-workings of it all. Here's how I currently understand it :

Workunit [insert workunit name].001 gets sent out to (hypothetically) 5 people.

User 1 processes it for an hour, and returns 6 structures.
User 2 processes it for 2 hours, and returns 15 structures.
User 3 goes for 4 hours and returns 45 structures.
User 4 does the full 8 hours, and returns the max of 99 structures, but ends early at 7 hours 30 minutes.

(again, hypothetical figures)
#1 claims 60 credit
#2 claims 120 credit
#3 claims 480 credit
#4 claims 900 credit

so... then you've got 4 seperate results for 1 workunit? How is credit canonical for User #3, or 4?

Assuming even if selecting your processing time preference will limit you to workunits that are only sent to like-setting machines, (I.E. once a workunit gets tagged as 4 hour processing times, only people with this preference can d/l them.. etc) Then at what point does the extra time become redundant?

well, i assume that people who want each workunit to run for a long time, will only get workunits that would have otherwise been short.

also if they need more results for a structure, then they'll issue more workunits, if there's enough, then they'll stop issueing WUs for that sturcture

this is only a guess, and i could be completely wrong
but in a project such as this (or any really), having more results is always good

As far as I can tell, so far. The time preference seems to be working. I set my prefernces to 2 hours for the my first batch and all finished right around that 2 hour mark.

I have changed my prefences, to 8 hours, for the next batch. So, we'll see how that goes.

Good stuff, looking good so far.

Thanks Rosetta team.

Joel

---

well, i assume that people who want each workunit to run for a long time, will only get workunits that would have otherwise been short.

also if they need more results for a structure, then they'll issue more workunits, if there's enough, then they'll stop issueing WUs for that sturcture

this is only a guess, and i could be completely wrong
but in a project such as this (or any really), having more results is always good

oops, forgot about credit
well currently there's only 1 result per WU, so a host will just be granted the ammount they claim

for multiple hosts, i don't know, an official will have to answer that one

Preferences are not by pc, we only have "home work school" to select

In my "home" I have 1 pc @ 166 mhz
and another pc @ 5000 mhz

So, I can select 8 hours of work to "home"

Does this means that after 8 hours of cpu time
the slow pc, as well the fast pc
have done their job(s) ?

---

Click signature for global team stats

[edit]lol was a dumb question [/edit]

Preferences are not by pc, we only have "home work school" to select

In my "home" I have 1 pc @ 166 mhz
and another pc @ 5000 mhz

So, I can select 8 hours of work to "home"

Does this means that after 8 hours of cpu time
the slow pc, as well the fast pc
have done their job(s) ?

Short answer yes, but not exactly after 8H.

From how I understand things it works like this. If you set the preference to 8H the target runtime for the result is 8H. It wont be exactly 8H because it finishes the last started predicted structure. So every time the result completes a structure it checks if it have used more then 8H of processing time and estimates whether or not the next structure will take it over 8H.

So if the last structure take about 2H, the result actual time could be 6-10H

---

Set to 4 days, update & many ask 4 wu later, first wu ran 257 seconds
2710

---

Set to 4 days, update & many ask 4 wu later, first wu ran 257 seconds
2710

This is unusual. Are you using a beta boinc client version? It shows version 5.3.6.

---

5.3.6 is a developmental version built for Gridrepublic, As far as I know it wasn't officially built to be an officially released version.

Edit, 5.3.2, 5.3.3, and 5.3.6 were made for Grid republic. See Email from Rom below:

[boinc_alpha] Dev Build 5.3.3 Inbox

Rom Walton to boinc_alpha
More options 12/19/05

Howdy Folks,

For those who are closely watching the download folder, you do not
need to worry about testing this release. This release was for the
GridRepublic folks to test some API changes.

When we are further along we'll start the next round of client
release testing.

Thanks in advance.

----- Rom

At first, I didn't set this preference, & it appears that all of my workunits were processing for 1 hour or less. I have now changed my preference to 2 hour workunits, and clicked "Update", but it didn't give me any message in the "messages" tab of the BOINCMGR telling me that the preference had changed. Surely some kind of message letting me know that my preferences have changed should be there yeah?

Some notes...

Changing the preference "Mid-Work" extended the processing time on the 2 workunits in progress by an hour. Those will now apparrently complete at the end of 2 hours total processing time.

With this in mind, is it safe to assume that those of us who do not set this preference have indeed defaulted to a preference of 1 hour, or was it just the luck of the draw that I got 40 1 hour workunits?

---

Aaron, did you update the project from whose website you changed the preferences? Updating the website means that your client will have to call home to see the changes. Highlight the name of the project you made the changes on and then click "update" on the projects tab of the manager.

I.E if you updated the Rosetta website, then go to the Projects tab, hightlight the rosetta project (right hand box, click "rosetta" till it turns blue), then click "Update". Then look at Messages tab, you should see it.