Message boards : Number crunching : Problems and Technical Issues with Rosetta@home
Previous · 1 . . . 333 · 334 · 335 · 336
Author | Message |
---|---|
Tom M Send message Joined: 20 Jun 17 Posts: 128 Credit: 28,863,853 RAC: 108,811 ![]() |
I have been watching my Rosetta tasks. Even with the "12 hours requested" I am regularly getting what appear to be 8 hour tasks. What I am not getting is the 2-3 hour tasks that seem to be the group average for the beta task on the server page. Is there ANY chance a 2 or 3 hour task is more productive? A lot of volunteers seem to be going with it. Help, my tagline is missing..... Help, my tagline is......... Help, m........ Hel..... |
kotenok2000 Send message Joined: 22 Feb 11 Posts: 283 Credit: 530,487 RAC: 161 |
Rosetta tasks usually run for a set amount of time, and execute several models during that time, with diffrernt rng seeds. For some reason some workunit types run very fast, and produce lots of data . For example my task reached model 16 in 10 minutes of cpu time. |
Sid Celery Send message Joined: 11 Feb 08 Posts: 2340 Credit: 44,441,680 RAC: 28,869 ![]() |
I have been watching my Rosetta tasks. Even with the "12 hours requested" I am regularly getting what appear to be 8 hour tasks. 3hr runtimes aren't chosen by volunteers. They're 'default' runtimes that are screwed up within the task by the researchers. It's a mistake (IMO but I'm convinced I'm right). Default runtimes are <all> intended to be 8hrs. That's why Boinc is forced by Rosetta to show all unstarted tasks as 8hrs, even if other settings contradict that runtime. The task runtimes screwed up by researchers only run 3hrs by mistake. Those set to be a different time by the volunteer (eg you and me at 12hrs) run that time, but Boinc only realises 2/3rds or 3/4s through the task to adjust the remaining time - whether up to 12hrs or down to 3hrs. <No chance> the shorter runtime is more productive. I don't think <any> change to runtime improves credit/hr, except the start/stop overhead is less significant for longer tasks and shorter tasks waste the work that's provided to us, so we may run out of tasks sooner than expected. <Never> run any less than 8hrs (intentionally). If your runtime setting is "default" and you mean that to be 8hrs, better (currently) to set runtime explicitly to 8hrs, not 'default' Credit is awarded for the number of "decoys" completed <within> each task within your chosen runtime. The quicker your machine, the faster each decoy is completed, the more decoys you can complete within your runtime, the more credit you get. That's essentially it. After each decoy, the average time per decoy is worked out. If you have sufficient runtime left to complete another decoy, you do so. If you don't, the task ends. That's why tasks don't run exactly to your runtime. Sometimes a bit shorter, sometimes a bit longer. It's also why the countdown on runtime never drops below 10mins remaining, but then suddenly ends. The task doesn't ever know when the current decoy will complete until it does. Then sees there isn't time to do another, so it ends. ![]() ![]() |
Sid Celery Send message Joined: 11 Feb 08 Posts: 2340 Credit: 44,441,680 RAC: 28,869 ![]() |
Two more Validate errors tonight, meaning 2x12hr tasks not being awarded credit. Another unheard appeal for the daily job that cleans this up to be reinstated. Probably caused by some disk errors I'm getting locally, but annoying nonetheless :( ![]() ![]() |
Sid Celery Send message Joined: 11 Feb 08 Posts: 2340 Credit: 44,441,680 RAC: 28,869 ![]() |
I note that this host: https://boinc.bakerlab.org/rosetta/show_host_detail.php?hostid=6282139 I've got another idle few minutes to do some investigating. We worked out the system you were comparing to was more powerful than yours, explaining why it had better results. Working out its credit over the last 11 24hr tasks returned it's averaging 908 credits/task Looking at yours now, over the last 20 12hr tasks returned you're averaging 444.5 credits/task - equivalent to 889 credits/task if running 24hrs Still behind, but now very much closer. Also, your error'd tasks have reduced from about 1100 out of ~3000 (I worked out a while back it was 27% of tasks you downloaded) to 201 out of 2153 - 9.3% - and it'll drop down further once the older tasks age out. Much cleaner. Comparing with yourself, using your info at Boincstats Pre adjustments you made here, from April 1st to May 8th, your average credit/day was 95,340 Since then it averages 116,430 - an increase of 22% per day. Tbh I didn't expect any increase at all, as nothing we all suggested should have made any difference, but maybe by ensuring you didn't get timed out tasks and cancellations from the server and didn't miss any deadlines there was some free benefit in there none of us noticed. I suspect it's just a matter of getting all the credit your runtime deserved, rather than missing out on bits and pieces here or there. Either way, more is more. No tasks are lost nor hoarded, no deadlines missed, no credits lost, no threads unutilised, quicker turnaround times, fewer server hits. So much winning for everyone. A highly productive exercise. ![]() ![]() |
Message boards :
Number crunching :
Problems and Technical Issues with Rosetta@home
©2025 University of Washington
https://www.bakerlab.org