CPU Run Time preference

Message boards : Current tests : CPU Run Time preference

To post messages, you must log in.

Previous · 1 · 2 · 3 · 4 · Next

AuthorMessage
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 266 - Posted: 19 Feb 2006, 0:02:30 UTC
Last modified: 19 Feb 2006, 0:18:10 UTC

OK I got an error now. My Celeron 500, 256M ram, Win98SE, Ralph Host 103 has had a computation error. This unit produced 20 successful returns with the Ralph time pref set to \"not selected\", the first WU with it set to 2 hours has had a Computation error at 02:01:00. this is the WU

5133 4850 18 Feb 2006 13:42:21 UTC 19 Feb 2006 0:02:27 UTC Over Client error Computing 7,260.00 4.85 ---

I suspect it has to do with the way win98se uses a wall clock.

tony

NOTE: Further up/down in this thread is more on this hosts set up and history

Edit, the first 20 were 4.83 and the ones of this run are 4.85, don\'t know if it matters, but there it is.

Also, the one that failed was not on my machine when I updated prefs, so it wasn\'t a matter of changed prefs while running.
ID: 266 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 272 - Posted: 19 Feb 2006, 0:32:11 UTC

Note: I changed my prefs back to \"not selected\" on CPU run time. did the project update, still don\'t see it on the messages tab, then suspended the only other project on host 103, Ralph is now running. I\'ll know in an hour whether or not it\'s a 4.85/4.83 thing causing this computation error.
ID: 272 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 281 - Posted: 19 Feb 2006, 1:34:14 UTC
Last modified: 19 Feb 2006, 1:38:34 UTC

As I sit here staring at the screen, I wonder:

The other difference in WUs on host 103 are that they were 4.83 HBLR wus that ran under my \"not selected\" preference, and the new ones are 4.85 Barcode WUs. This first WU after I changed back to \"not selected\" sat at 1% for 16 minutes, then sat at 1.78% for 10 or so minutes, then the percentage quickly ran to 51.67% were it stay for nearly 20 minutes and just now (at the 1:00:00 mark literally jumped to 74%.

I\'m coming to the conclusion that these wus are different and I can\'t really use any comparisons between 4.83 successes and 4.85 failures to find any meaningful conclusions (read I\'m wasting my time trying). I need to compare apples to apples and \"Barcodes\" to \"Barcodes\". Am I right here?

Another Question:

When my scheduler requests work, are the requests based upon the existing CPU time preference setting? Is changing that Preference setting after work is on your puter supposed to work on existing WUs? Or will we have to wait to burn through the existing wus before our preferences work again?
ID: 281 · Report as offensive    Reply Quote
Profile dekim
Volunteer moderator
Project administrator
Project developer
Project scientist

Send message
Joined: 20 Jan 06
Posts: 221
Credit: 527,409
RAC: 0
Message 282 - Posted: 19 Feb 2006, 1:37:28 UTC

Not selected will default back to 1 hour on Ralph w/ 4.85. It didn\'t with 4.83. I\'ll make it more obvious in the preferences page.
ID: 282 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 283 - Posted: 19 Feb 2006, 1:39:39 UTC - in response to Message 282.  

Not selected will default back to 1 hour on Ralph w/ 4.85. It didn\'t with 4.83. I\'ll make it more obvious in the preferences page.

THanks, I was editting my previous comment while you were typing your reply. Could you look at the last paragraph I wrote?
ID: 283 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 286 - Posted: 19 Feb 2006, 2:08:50 UTC

OK, It\'s done and successfully:

5134 4851 18 Feb 2006 13:42:21 UTC 19 Feb 2006 2:09:08 UTC Over Success Done 5,639.00 3.77 3.77

It stuck at 74.20% done from exactly 1:00:00 cpu time for 33 minutes and change it was at Model 5 and I keep seeing the steps move every so slowly. At 1:33:?? it jumped to 100% done and uploaded.

So with my preference at 2 hours a 4.85 barcode failed, at \"not selected\" it finished in 1:33:??. Does this help?

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

Send message
Joined: 20 Jan 06
Posts: 221
Credit: 527,409
RAC: 0
Message 288 - Posted: 19 Feb 2006, 2:16:56 UTC

Changes to the preferences should carry over to currently running work units when you update the project. The scheduler does not use this value for work distribution and we are aware that there will be issues with having inaccurate run time estimates (which are based on the rsc_fpops_est value we give for each work unit), and with long target cpu run times possibly reaching the work unit\'s expiration depending on how much the computer is used and what the resource share is. We will be monitoring this and adjusting accordingly. We will also increase the delay bound (expiration) to two weeks instead of one for the next batch of work units.
ID: 288 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 289 - Posted: 19 Feb 2006, 3:09:36 UTC
Last modified: 19 Feb 2006, 3:11:35 UTC

I left my Ralph pref to \"not selected\". I let my next to last 4.85 Barcode run on host 103. From the start to 00:30:00 it displayed 1% then finished model 1, at 00:30:001 it started model 2 and jumped to 38.54%, where it stayed until 00:59:01 when it jumped to 100% and uploaded. I noticed it was at Model 2 step 23410.

This is that Wu:

5135 4852 18 Feb 2006 13:42:21 UTC 19 Feb 2006 3:12:34 UTC Over Success Done 3,541.00 2.37 2.37
ID: 289 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 290 - Posted: 19 Feb 2006, 4:48:33 UTC
Last modified: 19 Feb 2006, 4:50:49 UTC

For my last 4.85 on host 103 I changed my prefs from \"not selected\" back to \"2 hours\" at 07:16 after the start of the program. If finished successfully whereas the first 4.85 did not at the same setting, unless changing the setting midstream stopped the second from failing.

From start to somewhere between 22 and 28 minutes it stayed at 1%, then jumped to 18.20 and stayed there until Model 2 was finished at 01:19:36. It then jumped to 61.7% until completion at 01:37:?? cpu time.

Is it safe to assume that the program just places a 1% complete figure up at the start of every WU then successive % completion updates are triggered by an event, and that the event is the completion of a model?

If so then % completed update frequency would be completely dependent upon the speed of the host. Is this so?

If so, then are the people getting the \"1% bug\" ever getting past model 1?

tony
ID: 290 · Report as offensive    Reply Quote
Lee Carre

Send message
Joined: 16 Feb 06
Posts: 21
Credit: 2,102
RAC: 0
Message 331 - Posted: 19 Feb 2006, 20:00:48 UTC - in response to Message 290.  

If so, then are the people getting the \"1% bug\" ever getting past model 1?

very doubtful
ID: 331 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 353 - Posted: 20 Feb 2006, 6:13:15 UTC - in response to Message 290.  
Last modified: 20 Feb 2006, 6:16:25 UTC

For my last 4.85 on host 103 I changed my prefs from \"not selected\" back to \"2 hours\" at 07:16 after the start of the program. If finished successfully whereas the first 4.85 did not at the same setting, unless changing the setting midstream stopped the second from failing.

From start to somewhere between 22 and 28 minutes it stayed at 1%, then jumped to 18.20 and stayed there until Model 2 was finished at 01:19:36. It then jumped to 61.7% until completion at 01:37:?? cpu time.

Is it safe to assume that the program just places a 1% complete figure up at the start of every WU then successive % completion updates are triggered by an event, and that the event is the completion of a model?

If so then % completed update frequency would be completely dependent upon the speed of the host. Is this so?

If so, then are the people getting the \"1% bug\" ever getting past model 1?

tony



You have a good grasp of this. The 1% occurs at the start, additional updates to the % occur at model completions and the WU will checkpoint at those times. The % complete update interval is very dependant on CPU speed (as is the case with all BOINC projects). And people who get stuck at 1% are usually NOT completing the first model, and that is why they get hung up. After the swap the WU falls back to the last checkpoint and picks up the work, if the keep in memory is set to no.

Hopefully the more frequent checkpointing will fix this. But it might still be possible for people to set slower machines to swap and such short intervals that they might be able to induce a 1% hang anyway. Or if later models take longer run times, the hang might occur at some other point in the process. So I would recommed keeping the swap time set to something like 60-90 min just to be safe.

But keep in mind that this is just one of the two flavors of hang. The other flavor is far more complex, and does not seem to be related to client settings.


Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact
ID: 353 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 368 - Posted: 20 Feb 2006, 13:51:40 UTC

I feel I\'ve run my hosts long enough on the 2 hour cpu time pref. Other than the problems listed about host 103, I\'ve seen no issues with the 2 hour pref.

Here\'s the WUS done during that period:

Host 103
5136 4853 18 Feb 2006 13:42:21 UTC 19 Feb 2006 4:46:02 UTC Over Success Done 5,856.00 3.91 3.91
5135 4852 18 Feb 2006 13:42:21 UTC 19 Feb 2006 3:12:34 UTC Over Success Done 3,541.00 2.37 2.37
5134 4851 18 Feb 2006 13:42:21 UTC 19 Feb 2006 2:09:08 UTC Over Success Done 5,639.00 3.77 3.77
5133 4850 18 Feb 2006 13:42:21 UTC 19 Feb 2006 0:02:27 UTC Over Client error Computing 7,260.00 4.85 ---
5132 4849 18 Feb 2006 13:42:21 UTC 18 Feb 2006 23:11:22 UTC Over Success Done 4,855.00 3.24 3.24
5131 4848 18 Feb 2006 13:42:21 UTC 18 Feb 2006 23:11:22 UTC Over Success Done 8,773.00 5.86 5.86

Host 64
None done

Host 66
1527 1492 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,126.27 26.65 26.65
1526 1491 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,050.73 26.37 26.37
1525 1490 16 Feb 2006 0:37:25 UTC 18 Feb 2006 21:16:26 UTC Over Success Done 7,241.86 27.08 27.08
1524 1489 16 Feb 2006 0:37:25 UTC 18 Feb 2006 21:16:26 UTC Over Success Done 7,100.19 26.55 26.55
1523 1488 16 Feb 2006 0:37:25 UTC 18 Feb 2006 17:58:41 UTC Over Success Done 7,188.95 26.89 26.89
1463 1428 16 Feb 2006 0:37:25 UTC 20 Feb 2006 12:54:44 UTC Over Success Done 7,219.59 27.00 27.00
1462 1427 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,168.48 26.81 26.81
1461 1426 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,161.34 26.78 26.78
1458 1423 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,184.36 26.87 26.87
1457 1422 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,132.44 26.67 26.67
1456 1421 16 Feb 2006 0:37:25 UTC 20 Feb 2006 3:16:28 UTC Over Success Done 7,148.88 26.74 26.74
1455 1420 16 Feb 2006 0:37:25 UTC 19 Feb 2006 11:29:52 UTC Over Success Done 7,266.20 27.17 27.17
1454 1419 16 Feb 2006 0:37:25 UTC 19 Feb 2006 6:07:44 UTC Over Success Done 6,014.48 22.49 22.49
1453 1418 16 Feb 2006 0:37:25 UTC 19 Feb 2006 3:23:50 UTC Over Success Done 7,129.23 26.66 26.66
1407 1372 16 Feb 2006 0:37:25 UTC 18 Feb 2006 17:58:41 UTC Over Success Done 7,080.91 26.48 26.48

Host 67
5339 3275 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,447.91 9.35 9.35
5338 3270 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,799.58 9.86 9.86
5337 3269 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,240.47 9.05 9.05
5336 3268 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 6,952.34 10.09 10.09
5335 3267 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 5,681.56 8.24 8.24
5334 3266 18 Feb 2006 20:57:47 UTC 20 Feb 2006 2:42:30 UTC Over Success Done 6,554.06 9.51 9.51
5333 3265 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 5,127.38 7.44 7.44
5332 3263 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 6,820.70 9.90 9.90
5331 3262 18 Feb 2006 20:57:47 UTC 19 Feb 2006 21:48:40 UTC Over Success Done 6,499.95 9.43 9.43
5330 3214 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 6,497.31 9.43 9.43
5329 3200 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 5,810.47 8.43 8.43
5328 3199 18 Feb 2006 20:57:47 UTC 19 Feb 2006 15:53:36 UTC Over Success Done 6,148.36 8.92 8.92
5327 3198 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 5,207.73 7.56 7.56
5326 3197 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 3,641.36 5.28 5.28
5325 3196 18 Feb 2006 20:57:47 UTC 19 Feb 2006 11:28:17 UTC Over Success Done 6,249.14 9.07 9.07
5320 3159 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,757.64 9.80 9.80
5319 3158 18 Feb 2006 20:57:47 UTC 20 Feb 2006 12:11:03 UTC Over Success Done 6,546.25 9.50 9.50

Note: all seems well with the 2 hour pref. I\'m now switching to the 4 hour pref.
ID: 368 · Report as offensive    Reply Quote
Profile Astro

Send message
Joined: 16 Feb 06
Posts: 141
Credit: 32,977
RAC: 0
Message 369 - Posted: 20 Feb 2006, 14:02:07 UTC

Continued note: It would be nice to see a message in the Messages tab telling users that the updated prefs were recognized. I still can\'t tell if it took and the only way to tell is after it runs a wu.

I have only recieved the following from my post to the mail list:

David Sutton to me, boinc_dev
More options Feb 19 (1 day ago)

From the looks of it BOINC only displays messages about preferences when you
change the default, home, school, works tabs. The setting to change CPU for
RALPH isn\'t contained within those settings probally because it would try to
effect all other BOINC projects running.

ID: 369 · Report as offensive    Reply Quote
Aaron Finney

Send message
Joined: 16 Feb 06
Posts: 56
Credit: 1,457
RAC: 0
Message 398 - Posted: 20 Feb 2006, 21:02:53 UTC
Last modified: 20 Feb 2006, 21:04:11 UTC

I\'ve tried all preferences, the default (1 hour), the 2 hour, 4 hour, 8 hour, 16 hour, 1 day, 2 day, and 4 day.

The only workunit that has failed was due to the \"leave application in memory=NO\" bug, and crashed after 25 hours on the 4.84 application version while it was preempted due to benchmark running. (see the bug report section.)

Otherwise, this setting appears to be working flawlessly, and IMHO, the appmem=no bug is not dependant on the CPURuntime setting.

Notes :

1. Changing the preference to longer time \"mid-work\" will affect running workunits, if the BOINCMGR updates the project at that time.

2. Similarly, if the preference is changed to shorter time, this will also affect running workunits, even if the run-time is currently WELL over the new preference. I.E. If you have 2 workunits that have been running for 24 hours and switch the preference to \"run work for 2 hours\", it will finish the current model, then upload the work to the server without complaint after.

3. Users COULD theoretically push work WAY WAYYYYY PAST it\'s deadline by downloading a large batch of work at the 2 hour preference, and then changing the work to a 4 day preference after downloading 20-30 workunits. Some sort of safety measure should be put into place to keep this from happening. Perhaps changing the preference to a longer time should extend the deadline for work the user currently has downloaded accordingly, or it should flash some sort of warning message about how updating the client with large caches could make the workunits useless. {{{Please note : While it is easy and quick to say on this issue \"Well, then don\'t keep large cache\'s\" or \"people need to use their heads\" or \"don\'t change and update mid-work\" Those statements always look good on paper, but never quite work out in reality. You have to plan for the lowest common denominator, and you should assume that that person is a complete fool. (and knows nothing of cache management or EDF) }}}
ID: 398 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 399 - Posted: 20 Feb 2006, 21:15:18 UTC - in response to Message 398.  
Last modified: 20 Feb 2006, 21:18:32 UTC

I\'ve tried all preferences, the default (1 hour), the 2 hour, 4 hour, 8 hour, 16 hour, 1 day, 2 day, and 4 day.

The only workunit that has failed was due to the \"leave application in memory=NO\" bug, and crashed after 25 hours on the 4.84 application version while it was preempted due to benchmark running. (see the bug report section.)

Otherwise, this setting appears to be working flawlessly, and IMHO, the appmem=no bug is not dependant on the CPURuntime setting.

Notes :

1. Changing the preference to longer time \"mid-work\" will affect running workunits, if the BOINCMGR updates the project at that time.

2. Similarly, if the preference is changed to shorter time, this will also affect running workunits, even if the run-time is currently WELL over the new preference. I.E. If you have 2 workunits that have been running for 24 hours and switch the preference to \"run work for 2 hours\", it will finish the current model, then upload the work to the server without complaint after.

3. Users COULD theoretically push work WAY WAYYYYY PAST it\'s deadline by downloading a large batch of work at the 2 hour preference, and then changing the work to a 4 day preference after downloading 20-30 workunits. Some sort of safety measure should be put into place to keep this from happening. Perhaps changing the preference to a longer time should extend the deadline for work the user currently has downloaded accordingly, or it should flash some sort of warning message about how updating the client with large caches could make the workunits useless. {{{Please note : While it is easy and quick to say on this issue \"Well, then don\'t keep large cache\'s\" or \"people need to use their heads\" or \"don\'t change and update mid-work\" Those statements always look good on paper, but never quite work out in reality. You have to plan for the lowest common denominator, and you should assume that that person is a complete fool. (and knows nothing of cache management or EDF) }}}




Good info and good report on the feature. The project guys are aware of the issues you point out with the time adjustment. They are thinking of how to deal with it right now. Something is in the works, but I have not bothered them with a lot of questions on it. They will probably make this a test item in the next ALPHA version, because it is a serious problem. Right now they are still looking at the hangs. It looks like they have nailed the Max time issue as reported here, and the Time adjustment will help the bandwidth issue.

But the fix for the issue you mentioned will defeat the time setting being used to solve the bandwidth problem. So the answer is complicated.


Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact
ID: 399 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 439 - Posted: 21 Feb 2006, 20:12:00 UTC - in response to Message 402.  

Aaron,

I can\'t edit it but I can repost it as a quote and make the change.


I\'ve tried all preferences, the default (1 hour), the 2 hour, 4 hour, 8 hour, 16 hour, 1 day, 2 day, and 4 day.

The only workunit that has failed was due to the \"leave application in memory=NO\" bug, and crashed after 25 hours on the 4.84 application version while it was preempted due to benchmark running. (see the bug report section.)

Otherwise, this setting appears to be working flawlessly, and IMHO, the appmem=no bug is not dependant on the CPURuntime setting.

Notes :

1. Changing the preference to longer time \"mid-work\" will affect running workunits, if the BOINCMGR updates the project at that time.

2. Similarly, if the preference is changed to shorter time, this will also affect running workunits, even if the run-time is currently WELL over the new preference. I.E. If you have 2 workunits that have been running for 24 hours and switch the preference to \"run work for 2 hours\", it will finish the current model, then upload the work to the server without complaint after.

3. Users COULD theoretically push work WAY WAYYYYY PAST it\'s deadline by downloading a large batch of work at the 2 hour preference, and then changing the work to a 4 day preference after downloading 20-30 workunits. Some sort of safety measure should be put into place to keep this from happening. Perhaps changing the preference to a longer time should extend the deadline for work the user currently has downloaded accordingly, or it should flash some sort of warning message about how updating the client with large caches could make the workunits useless. {{{Please note : While it is easy and quick to say on this issue \"Well, then don\'t keep large cache\'s\" or \"people need to use their heads\" or \"don\'t change and update mid-work\" Those statements always look good on paper, but never quite work out in reality. You have to plan for the lowest common denominator, and you should assume that that person is a complete fool. (and knows nothing of cache management or EDF) }}}




Good info and good report on the feature. The project guys are aware of the issues you point out with the time adjustment. They are thinking of how to deal with it right now. Something is in the works, but I have not bothered them with a lot of questions on it. They will probably make this a test item in the next ALPHA version, because it is a serious problem. Right now they are still looking at the hangs. It looks like they have nailed the Max time issue as reported here, and the Time adjustment will help the bandwidth issue.

But the fix for the issue you mentioned will defeat the time setting being used to solve the bandwidth problem. So the answer is complicated.



Well, I wrote a topic on something that would have dealt with this exact issue once, and it was almost immediately shot down by closed minded idiots. You can read it here...

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=158 - here

The specific post I would read is

http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=158#1578 - here

by that point I was getting a little pissy, but it\'s a good read nonetheless.


NOTE: Text edited at users request to change the post number from 1573 to 1578. And to add the direct links for the threads mentioned.
Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact
ID: 439 · Report as offensive    Reply Quote
Profile Morgan the Gold

Send message
Joined: 15 Feb 06
Posts: 8
Credit: 182,333
RAC: 0
Message 465 - Posted: 22 Feb 2006, 6:07:15 UTC
Last modified: 22 Feb 2006, 6:32:50 UTC

machine 45 51hours then the other wu was 12 min
3457 and 3882

pref still set to 4 days no mo wu

p.s. there is no \"last 20\"/\"previous 20\" on the second &ct pages of results in user results link

ID: 465 · Report as offensive    Reply Quote
[B^S] sTrey
Avatar

Send message
Joined: 15 Feb 06
Posts: 58
Credit: 15,430
RAC: 0
Message 523 - Posted: 23 Feb 2006, 9:49:44 UTC

My run-time pref was \"not selected\" and I noticed the first of my latest batch of Ralph wu\'s put in 5 hrs with, it claimed, about 3 to go. I just changed my pref to 2 hours and it finished, as I\'d expect given the desciptions of behavior when changing the prefs mid-wu.

I read somewhere that Rosetta will use 8 hours for the default, so my question is are the tests set for production defaults now, else what happened to the 1 hr test default?
ID: 523 · Report as offensive    Reply Quote
Profile Morgan the Gold

Send message
Joined: 15 Feb 06
Posts: 8
Credit: 182,333
RAC: 0
Message 680 - Posted: 26 Feb 2006, 14:45:51 UTC

had that wu run 22 seconds long (4 days & 22 secs ) works on rosetta too.

ID: 680 · Report as offensive    Reply Quote
Moderator9
Volunteer moderator

Send message
Joined: 16 Feb 06
Posts: 251
Credit: 0
RAC: 0
Message 692 - Posted: 27 Feb 2006, 4:12:53 UTC - in response to Message 523.  

My run-time pref was \"not selected\" and I noticed the first of my latest batch of Ralph wu\'s put in 5 hrs with, it claimed, about 3 to go. I just changed my pref to 2 hours and it finished, as I\'d expect given the desciptions of behavior when changing the prefs mid-wu.

I read somewhere that Rosetta will use 8 hours for the default, so my question is are the tests set for production defaults now, else what happened to the 1 hr test default?


I seem to remember seeing a post from David Kim saying that he had increased the default run length for Ralph to test some things, but I can\'t find it now to point you to it. I think it was on the feedback forum, but I am not certain.

Moderator9
RALPH@home FAQs
RALPH@home Guidelines
Moderator Contact
ID: 692 · Report as offensive    Reply Quote
Previous · 1 · 2 · 3 · 4 · Next

Message boards : Current tests : CPU Run Time preference



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