Message boards : RALPH@home bug list : cpu_run_time_pref

To post messages, you must log in.


Send message
Joined: 16 Feb 06
Posts: 5
Credit: 777
RAC: 0
Message 150 - Posted: 17 Feb 2006, 15:49:05 UTC

This is more of a comment than a bug I guess, and it may be totally unimportant.

I had 2 WU\'s running on my HT machine with a run time setting of 4 hours. The second had 1 hour on it when the first was nearing completion. I then changed my online setting to 8 hours so any new work would go 8 instead of 4. To my surprise, and very neat, after reporting the first WU and doing the update triggered by that, it added 4 additional hours to the WU that was already underway.

My comment, though, is about the stamp in the stderr output file. There is no entry showing the time was ever set to increase, leaving only the entry for \"cpu_run_time_pref: 14400\". Considering some of the complaints/problems from standard Rosetta about WU run times and units getting stuck and such, should there not be an entry (if for no other reason than troubleshooting) showing that the cpu_run_time_pref was reset to 28,800 (or whatever it was really reset to)?

As it stands, just looking at this WU could lead to someone believing the program didn\'t work properly, as it says it should run 14,400 seconds, but it also says it really ran 29,014 seconds.

ID: 150 · 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 156 - Posted: 17 Feb 2006, 19:13:45 UTC

We can add the stamp to stderr each time the preference is changed.
ID: 156 · Report as offensive    Reply Quote

Message boards : RALPH@home bug list : cpu_run_time_pref

©2018 University of Washington