CPU Run Time preference

Message boards : Current tests : CPU Run Time preference

To post messages, you must log in.

1 · 2 · 3 · 4 · Next

AuthorMessage
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 250
Credit: 543,579
RAC: 0
Message 3 - Posted: 15 Feb 2006, 20:47:18 UTC
Last modified: 16 Feb 2006, 18:07:26 UTC

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.



ID: 3 · Report as offensive    Reply Quote
Aaron Finney

Send message
Joined: 16 Feb 06
Posts: 56
Credit: 1,457
RAC: 0
Message 21 - Posted: 16 Feb 2006, 5:56:14 UTC - in response to Message 3.  

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..
ID: 21 · Report as offensive    Reply Quote
doc :)

Send message
Joined: 16 Feb 06
Posts: 46
Credit: 4,437
RAC: 0
Message 25 - Posted: 16 Feb 2006, 6:57:12 UTC

looks like it is working as it should, for my first WU at least. :)
only missed the target cpu time by 5 minutes.
ID: 25 · Report as offensive    Reply Quote
Lee Carre

Send message
Joined: 16 Feb 06
Posts: 21
Credit: 2,102
RAC: 0
Message 49 - Posted: 16 Feb 2006, 14:46:34 UTC - in response to Message 21.  

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
ID: 49 · Report as offensive    Reply Quote
Lee Carre

Send message
Joined: 16 Feb 06
Posts: 21
Credit: 2,102
RAC: 0
Message 50 - Posted: 16 Feb 2006, 14:51:21 UTC
Last modified: 16 Feb 2006, 14:52:38 UTC

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?
ID: 50 · Report as offensive    Reply Quote
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 250
Credit: 543,579
RAC: 0
Message 53 - Posted: 16 Feb 2006, 16:39:25 UTC

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.
ID: 53 · Report as offensive    Reply Quote
Aaron Finney

Send message
Joined: 16 Feb 06
Posts: 56
Credit: 1,457
RAC: 0
Message 54 - Posted: 16 Feb 2006, 16:45:47 UTC - in response to Message 53.  
Last modified: 16 Feb 2006, 16:46:03 UTC

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?
ID: 54 · Report as offensive    Reply Quote
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 250
Credit: 543,579
RAC: 0
Message 59 - Posted: 16 Feb 2006, 18:07:13 UTC
Last modified: 16 Feb 2006, 18:10:05 UTC

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.
ID: 59 · Report as offensive    Reply Quote
Aaron Finney

Send message
Joined: 16 Feb 06
Posts: 56
Credit: 1,457
RAC: 0
Message 80 - Posted: 16 Feb 2006, 21:56:50 UTC - in response to Message 59.  

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?
ID: 80 · Report as offensive    Reply Quote
Lee Carre

Send message
Joined: 16 Feb 06
Posts: 21
Credit: 2,102
RAC: 0
Message 82 - Posted: 16 Feb 2006, 22:15:14 UTC - in response to Message 80.  

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
ID: 82 · Report as offensive    Reply Quote
JChojnacki
Avatar

Send message
Joined: 16 Feb 06
Posts: 2
Credit: 24,627
RAC: 0
Message 85 - Posted: 16 Feb 2006, 22:49:29 UTC
Last modified: 16 Feb 2006, 22:50:54 UTC

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

ID: 85 · Report as offensive    Reply Quote
Lee Carre

Send message
Joined: 16 Feb 06
Posts: 21
Credit: 2,102
RAC: 0
Message 93 - Posted: 17 Feb 2006, 0:00:58 UTC - in response to Message 82.  
Last modified: 17 Feb 2006, 0:01:20 UTC

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
ID: 93 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 114 - Posted: 17 Feb 2006, 4:11:21 UTC - in response to Message 93.  

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


Your assessment is reasonable.

Currently the Rosetta project (and Ralph for that matter) do not use the "canonical" results system for credit awards. There has been no final announcement as to if or when Rosetta might move to such a system. The last announcement on this subject stated that more work could be done if the work Units were only processed once. This has raised issues for many as to the fairness of the credits that are awarded, but gathering more results in a shorter time frame is critical to the project goals.

In any case, the answer to the question you pose is that under the current award system each result will be awarded the credit claimed. So it will not matter how many structures are processed far a particular Work Unit by a particular machine, the credit claim will be based on the same factors as it would for any Work Unit, at any project. The only difference here is that the claimed credit is awarded without canonical comparisons.

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact
ID: 114 · Report as offensive    Reply Quote
Profile Carlos_Pfitzner
Avatar

Send message
Joined: 16 Feb 06
Posts: 182
Credit: 22,792
RAC: 0
Message 141 - Posted: 17 Feb 2006, 6:50:09 UTC

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
ID: 141 · Report as offensive    Reply Quote
Profile Morgan the Gold

Send message
Joined: 15 Feb 06
Posts: 8
Credit: 187,911
RAC: 0
Message 143 - Posted: 17 Feb 2006, 7:49:21 UTC
Last modified: 17 Feb 2006, 7:52:47 UTC

[edit]lol was a dumb question [/edit]
ID: 143 · Report as offensive    Reply Quote
Ziran

Send message
Joined: 16 Feb 06
Posts: 1
Credit: 81
RAC: 0
Message 146 - Posted: 17 Feb 2006, 9:53:51 UTC - in response to Message 141.  

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

ID: 146 · Report as offensive    Reply Quote
Profile Morgan the Gold

Send message
Joined: 15 Feb 06
Posts: 8
Credit: 187,911
RAC: 0
Message 149 - Posted: 17 Feb 2006, 15:25:26 UTC
Last modified: 17 Feb 2006, 15:40:48 UTC

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

ID: 149 · Report as offensive    Reply Quote
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 250
Credit: 543,579
RAC: 0
Message 157 - Posted: 17 Feb 2006, 19:30:48 UTC - in response to Message 149.  

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.
ID: 157 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 158 - Posted: 17 Feb 2006, 19:35:36 UTC
Last modified: 17 Feb 2006, 19:42:21 UTC

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

ID: 158 · Report as offensive    Reply Quote
Aaron Finney

Send message
Joined: 16 Feb 06
Posts: 56
Credit: 1,457
RAC: 0
Message 159 - Posted: 17 Feb 2006, 19:55:44 UTC - in response to Message 3.  

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?
ID: 159 · Report as offensive    Reply Quote
1 · 2 · 3 · 4 · Next

Message boards : Current tests : CPU Run Time preference



©2024 University of Washington
http://www.bakerlab.org