Awesome Thankyou!

Big thanks for the reply talking about whether this helping. Would love to see further publications on the progress being made with the influx of users, even though it may be lackluster or unintelligible to the layman.

I also get that doing the work itself is of paramount importance, and that takes priority over belly rubs. Even weekly drops of what's on the docket I think would help keep existing users excited and help fuel new users as well.

Thank you again!

has <run out> of tasks right now

As far as I can tell it hasn't run out. I've been submitting to the R@H queue and apparently my jobs need 2G of ram (sorry 1G users...). But with that in mind, I see 1.4M jobs lined up and ready to go.


Also, on the topic of job length, here's the tricky scenario I'm in. Let's say for instance I have 1M proteins that need to be designed. My goal is to do this as fast as possible. But how to best do this? To avoid wasting your CPU cycles, I need to make sure that all jobs have enough proteins to go for 8 hours.

I submit this way, knowing full-well that not all of the proteins will be designed. Some people design for fewer hours, and some people just have slow computers (which are both fine btw). There's also another case where someone is running for 8 hours, but the job gets interrupted a bunch of times and doesn't finish for 2 weeks.

With this in mind, I wait about 2 days after all the jobs have started, at which point I see what has finished, and resubmit anything that hasn't come back yet. This process has to repeat a few times with each submission getting closer and closer to 100% completion, but I typically give up at around 80%-90% and then call it a day. (I don't necessarily need all the outputs, I just need a lot) (Also, when I resubmit, I don't give up on jobs currently running, I just give someone else the same job too.)

So with that in mind, yes, 8 hours is better than 4 hours because our server is under a lot of load at the moment. (More users and these design jobs are roughly 100X worse on the server). But, more importantly than the number of hours is the turnaround time, so if your 8 hour jobs are taking a week to finish, there's nothing wrong with going 4 hours.

First of all, thank you for what you all do. I am currently running Rosetta on a laptop, a desktop, and trying to get work units for my 3 Android devices. Unfortunately, no matter how many times I reset or update, I haven't received one work unit on any Android device. Any advice? Thank you.

First of all, thank you for what you all do. I am currently running Rosetta on a laptop, a desktop, and trying to get work units for my 3 Android devices. Unfortunately, no matter how many times I reset or update, I haven't received one work unit on any Android device. Any advice? Thank you.

They haven't released units for Android for awhile. In the meantime, please run projects that actively use Android.

Universe@Home, World Community Grid and Asteroids@Home all have Android units available right now. The second Rosetta sends out Android units again (if ever), you'll know.

Since today there are some Android WUs at the Ralp@Home Project (The official alpha test project for Rosetta@home). If those run stable there might be new Android WUs for Rosetta as well. Maybe you can help testing those WUs at Ralp@Home.

has &lt;run out&gt; of tasks right now

As far as I can tell it hasn't run out. I've been submitting to the R@H queue and apparently my jobs need 2G of ram (sorry 1G users...). But with that in mind, I see 1.4M jobs lined up and ready to go.


Also, on the topic of job length, here's the tricky scenario I'm in. Let's say for instance I have 1M proteins that need to be designed. My goal is to do this as fast as possible. But how to best do this? To avoid wasting your CPU cycles, I need to make sure that all jobs have enough proteins to go for 8 hours.

I submit this way, knowing full-well that not all of the proteins will be designed. Some people design for fewer hours, and some people just have slow computers (which are both fine btw). There's also another case where someone is running for 8 hours, but the job gets interrupted a bunch of times and doesn't finish for 2 weeks.

With this in mind, I wait about 2 days after all the jobs have started, at which point I see what has finished, and resubmit anything that hasn't come back yet. This process has to repeat a few times with each submission getting closer and closer to 100% completion, but I typically give up at around 80%-90% and then call it a day. (I don't necessarily need all the outputs, I just need a lot) (Also, when I resubmit, I don't give up on jobs currently running, I just give someone else the same job too.)

So with that in mind, yes, 8 hours is better than 4 hours because our server is under a lot of load at the moment. (More users and these design jobs are roughly 100X worse on the server). But, more importantly than the number of hours is the turnaround time, so if your 8 hour jobs are taking a week to finish, there's nothing wrong with going 4 hours.

Thanks for this.

Have to ask as a noob, though - what is the max ideal turnaround time for a slow PC? The laptops I'm running WUs on can take 10-12 hours per WU - and I can abort the Rosetta queue so I'm not slowing the research down.

Thank you! Would love to help test! Pardon my ignorance, but how do I add Ralp@Home work units using the Android blank client? I don't see it listed in a list of projects.

Pardon my ignorance, but how do I add Ralp@Home work units using the Android blank client? I don't see it listed in a list of projects.

There are 3 points top right in project page of Android client, and "add a project by url".

---

Have to ask as a noob, though - what is the max ideal turnaround time for a slow PC? The laptops I'm running WUs on can take 10-12 hours per WU - and I can abort the Rosetta queue so I'm not slowing the research down.

I think they are all supposed to take around 8 hours (of cpu time) no matter how fast or slow the machine. They must be scaling the wus based on benchmarks.

Have to ask as a noob, though - what is the max ideal turnaround time for a slow PC? The laptops I'm running WUs on can take 10-12 hours per WU - and I can abort the Rosetta queue so I'm not slowing the research down.

I think they are all supposed to take around 8 hours (of cpu time) no matter how fast or slow the machine. They must be scaling the wus based on benchmarks.

To clarify - I asked about turnaround time (the time between downloading the WU and submitting it for validation) - as the project team member was talking about. They said they were more concerned about turnaround time, not CPU time. Thanks for trying to help, though!

Bcov,

Thanks for the explanation. I assume this is why some WU's end far earlier than the designated CPU time target on the prefs, because they computed all the protein work packaged in the WU. I have my my prefs set at 24 hours for now.

has &lt;run out&gt; of tasks right now

As far as I can tell it hasn't run out. I've been submitting to the R@H queue and apparently my jobs need 2G of ram (sorry 1G users...). But with that in mind, I see 1.4M jobs lined up and ready to go.

It was for a very short time - so short that it didn't exhaust buffers - and tasks started coming through again shortly after. A pre-emptive comment that was resolved before anyone noticed.

So with that in mind, yes, 8 hours is better than 4 hours because our server is under a lot of load at the moment. (More users and these design jobs are roughly 100X worse on the server). But, more importantly than the number of hours is the turnaround time, so if your 8 hour jobs are taking a week to finish, there's nothing wrong with going 4 hours.

Personally I hold 1.5 days buffer, plus the 8hr runtime, so everything I grab goes back in less than 2 days.

The subject's been discussed here before and you seem to confirm again it's the optimal balance of security of work for users and turnaround time for you.

As such, 4hr task runtimes only serve to double the hit on your servers, which you confirm they can ill-afford, for zero benefit.

If ever you guys need a quicker turnaround time, please pipe up. The adjustment for those who read here and pay attention is trivial.

---

Also, on the topic of job length, here's the tricky scenario I'm in. Let's say for instance I have 1M proteins that need to be designed. My goal is to do this as fast as possible. But how to best do this? To avoid wasting your CPU cycles, I need to make sure that all jobs have enough proteins to go for 8 hours.

And on this, I was just about to say something.
My 8-core PC has 16Gb RAM, running 6 tasks needing 1Gb, 1 needing 1.6Gb and 1 needing 2Gb. I'm only just fitting them in.
Same with a 4-core laptop with 8Gb running 4*1Gb tasks right now, but which reported insufficient memory earlier today. The reason is now obvious.
Lots of reports of problems with tasks atm. I'd inspect for demands on memory before reporting.

With the work being run atm, Rosetta is a very demanding project. Users may need to consider whether upgrades are required to support it fully, not just with RAM but also with CPU cooling.
And now may be the time to blow out all those dust-bunnies that've built up in your PC case to run cooler. A little bit of maintenance never did any harm. Make use of those masks you bought too!

---

Personally I hold 1.5 days buffer, plus the 8hr runtime, so everything I grab goes back in less than 2 days.

The subject's been discussed here before and you seem to confirm again it's the optimal balance of security of work for users and turnaround time for you.

Inadvertently it seems I provided the answer to later questions from others.
Any task buffer size you chose from the default values to these values are fine, but don't exceed them otherwise tasks are returned too late.

---

The international team CRUNCHERS SANS FRONTIERES is on board!
Thanks to the Rosetta@home project and its Admins for allowing us to participate in the fight against COVID-19.
Keep crunching hard!

---

Welcome to all new crunchers! It is time to crunch!
And it's interesting to learn more about how the project works.

---

Have to ask as a noob, though - what is the max ideal turnaround time for a slow PC? The laptops I'm running WUs on can take 10-12 hours per WU - and I can abort the Rosetta queue so I'm not slowing the research down.

I think they are all supposed to take around 8 hours (of cpu time) no matter how fast or slow the machine. They must be scaling the wus based on benchmarks.

To clarify - I asked about turnaround time (the time between downloading the WU and submitting it for validation) - as the project team member was talking about. They said they were more concerned about turnaround time, not CPU time. Thanks for trying to help, though!

The time per WU is based on a user preference for preferred runtime. Each machine, regardless of how fast it runs, tries to get as much done within that runtime preference as possible. Keep in mind that the preference refers to actual CPU time, not the "wall-clock" time (see the properties of a specific WU, where both times are shown).

All of the results are used. Regardless of how soon they were returned. I think they were simply saying that you don't need to babysit the machines. Try to set them up to get results returned within 48 hours if that is possible for your situation. You do this by reviewing your network preferences, and letting the machine run for a consistent number of hours per day, so the BOINC Manager can calibrate how much work to request to fill a cache of x.x days requested in the network preferences.

---

Rosetta Moderator: Mod.Sense

thats true
--
https://www.Sylphen.com

I agree with james. Lets get some priorities straight over there in the Lab. Doubled CPU time in the last short period... that is only for one reason, Covid19. Someone needs to do some rescheduling.