New work units (4.15) have arrived on my Linux machines.
But the time estimates are even shorter than usual, at less than 2 hours on my Ryzens.

Since I have set my profiles for 18 hours, way too many will download, and they could time out.
So I have set zero resource share on all my machines to just download one at a time until the estimates improve.

Good luck.

---

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

Mine run for 18 hours, because that is what I set them to.
You would initially get way too many short ones if you set BOINC to a 3 to 4 day buffer.

Insofar as I know, that setting does not change the run time. It is just that the initial time estimates are way off.
The initial estimate is usually 4 hours 30 minutes on my machines, but is even less now.

---

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

The deadlines assigned have nothing to do with how much work your machine requests. And runtimes are based on the runtime preference, not some fixed WU size.

---

Rosetta Moderator: Mod.Sense

New work units (4.15) have arrived on my Linux machines.
But the time estimates are even shorter than usual, at less than 2 hours on my Ryzens.

Since I have set my profiles for 18 hours, way too many will download, and they could time out.
So I have set zero resource share on all my machines to just download one at a time until the estimates improve.

Good luck.

Yes, I believe the new application version causes BOINC Manager to have to relearn how long your machine takes to crunch the tasks (i.e. how your runtime preference is set). Please wait until the runtime estimates are closer to your runtime preference, (waiting will help ensure you don't turn around and request more work as soon as you abort some tasks) and then abort those that stand no chance of getting started before expiration.

---

Rosetta Moderator: Mod.Sense

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.

That would make things worse than they are. Better to make the settings 0.1 day, and 0.01 additional days.
Will help to keep things under control till the Estimated times settle down again. And given the long runtimes for Rosetta tasks, that will take a while to occur (the more cores/threads processing work, the sooner it will happen).

---

Grant
Darwin NT

New work units (4.15) have arrived on my Linux machines.
But the time estimates are even shorter than usual, at less than 2 hours on my Ryzens.

Since I have set my profiles for 18 hours, way too many will download, and they could time out.
So I have set zero resource share on all my machines to just download one at a time until the estimates improve.

Good luck.

Yes, I believe the new application version causes BOINC Manager to have to relearn how long your machine takes to crunch the tasks (i.e. how your runtime preference is set). Please wait until the runtime estimates are closer to your runtime preference, (waiting will help ensure you don't turn around and request more work as soon as you abort some tasks) and then abort those that stand no chance of getting started before expiration.

Same here with the runtimes, but I left it.
But as each earlier (non 4.15) task got completed and reported, the expected runtime of the unstarted 4.15 tasks increased, and as they increased it affected what new tasks would come down.
I think (not certain) I'm about to complete and report my first 4.15 task and even before that's happened, later 4.15 tasks show an expected runtime of 6h20m or 6h45m.

tl;dr I left everything alone, runtime sorted itself out without me having to touch anything and I don't have an excessive buffer either

---

tl;dr I left everything alone, runtime sorted itself out without me having to touch anything and I don't have an excessive buffer either

You lucked out. It depends on the order of what they send you. It could go the wrong way.
I keep the default buffer of 0.1 + 0.5 days. That may be short enough to keep them from timing out, but I don't trust it.
The zero resource share is foolproof. I can increase it in a few days.

---

tl;dr I left everything alone, runtime sorted itself out without me having to touch anything and I don't have an excessive buffer either

You lucked out. It depends on the order of what they send you. It could go the wrong way.
I keep the default buffer of 0.1 + 0.5 days. That may be short enough to keep them from timing out, but I don't trust it.
The zero resource share is foolproof. I can increase it in a few days.

I'm not sure I did luck out. Somehow (and I really don't know how) when I completed a non-4.15 task and it reported, my unstarted 4.15 tasks increased in expected runtime. This can only be a Boinc (or project) thing, but it happened automatically.

It applies to me too - I'm a tinkerer by nature - but trust it and only intervene if you're not going to meet deadline. Mine handled it fine by doing that.
Do less work, not more.

---

4.16 is now the main app on OSX, and all my 4.16 WU's seem to be running short, but they all put out exactly 1,000 decoys each. Without knowing the nature of the research being done I can't tell if this is normal, but it's an eye opener.

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

The deadlines assigned have nothing to do with how much work your machine requests. And runtimes are based on the runtime preference, not some fixed WU size.

I know, but if I set 10 day + 10 day of additional work, I usually get projects with long deadlines, which many of them happen to be long units.

4.16 is now the main app on OSX, and all my 4.16 WU's seem to be running short, but they all put out exactly 1,000 decoys each.
Without knowing the nature of the research being done I can't tell if this is normal, but it's an eye opener.

This has happened before (a year or two back) and it seems like it's a hard-coded limit. Usually tasks don't create that many decoys.
It should be reported to Admin here to let him look at it.
Maybe it's right it's creating so many decoys, but maybe the task is running away with itself too. Only they'll know for sure.
On the plus side, hosts are getting the maximum from the task and the quicker the limit is reached the quicker it's reported and move onto a better task

---

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

The deadlines assigned have nothing to do with how much work your machine requests. And runtimes are based on the runtime preference, not some fixed WU size.

I know, but if I set 10 day + 10 day of additional work, I usually get projects with long deadlines, which many of them happen to be long units.

We used to have tasks with 8-day deadlines quite frequently, but since the recent changes I haven't see a single 8-day task. And certainly none longer for about 5 years.
It looks like we're now an exclusively 3-day-deadline project

---

4.16 is now the main app on OSX, and all my 4.16 WU's seem to be running short, but they all put out exactly 1,000 decoys each. Without knowing the nature of the research being done I can't tell if this is normal, but it's an eye opener.

Someone earlier today posted 1000 completed models. I couldn't hardly believe it, from a tablet PC? But their tasks showed success and no errors, no watchdog problems.

So, I conclude these are some of the fragment WUs bcov described, where there are a number of small proteins that they pre-crunch, and then build in to another WU that pairs it with COVID to see how well they might dock together.

The 1,000 certainly sounds like a hard limit built in to the WU. One case where the WU would not wait until your target runtime preference is reached. This limit varies for different work types. But big round numbers, and lower than expected runtimes would be classic signs. To continue churning out models at that rate ends up building rather uncomfortably large outfiles. So 1,000 is a compromise across the desirable factors.

---

Rosetta Moderator: Mod.Sense

The 1,000 certainly sounds like a hard limit built in to the WU. One case where the WU would not wait until your target runtime preference is reached. This limit varies for different work types. But big round numbers, and lower than expected runtimes would be classic signs. To continue churning out models at that rate ends up building rather uncomfortably large outfiles. So 1,000 is a compromise across the desirable factors.

Now that a few more have crunched, it's no longer all of them putting out 1,000 decoys, but sure seems like a large chunk are. Guessing it's something to do with what's being crunched vs the app doing the crunching.
Some examples:

https://boinc.bakerlab.org/rosetta/result.php?resultid=1148732970
https://boinc.bakerlab.org/rosetta/result.php?resultid=1148732840
https://boinc.bakerlab.org/rosetta/result.php?resultid=1148732920
https://boinc.bakerlab.org/rosetta/result.php?resultid=1148732926

Here's one that did it while still on 4.15 so perhaps it is research based and not app based: https://boinc.bakerlab.org/rosetta/result.php?resultid=1148450377

/edit Also that last one was from a windows box not my usual MacOS based boxes...

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

The deadlines assigned have nothing to do with how much work your machine requests. And runtimes are based on the runtime preference, not some fixed WU size.

I know, but if I set 10 day + 10 day of additional work, I usually get projects with long deadlines, which many of them happen to be long units.

We used to have tasks with 8-day deadlines quite frequently, but since the recent changes I haven't see a single 8-day task. And certainly none longer for about 5 years.
It looks like we're now an exclusively 3-day-deadline project

I've noticed the Covid 19 WUs on mobile get a 2 day deadline!
Those WUs run several hours on Android. Tough to get more than 6 loaded at the same time.

When you preload tasks increase the setting of 0.1 day, and 0.1 additional day in boinc mgr to 3 or 4.
you'll get Wu's with longer deadline, which also means a higher chance of getting Wu's that run longer.
Rosetta has mixed WUs, some of which run close to 10 hours.

The deadlines assigned have nothing to do with how much work your machine requests. And runtimes are based on the runtime preference, not some fixed WU size.

I know, but if I set 10 day + 10 day of additional work, I usually get projects with long deadlines, which many of them happen to be long units.

We used to have tasks with 8-day deadlines quite frequently, but since the recent changes I haven't see a single 8-day task. And certainly none longer for about 5 years.
It looks like we're now an exclusively 3-day-deadline project

I've noticed the Covid 19 WUs on mobile get a 2 day deadline!
Those WUs run several hours on Android. Tough to get more than 6 loaded at the same time.

No, definitely 3-day. Mine are here
And somehow I get them back a day early even though I'm not convinced my phone runs them very well (using 4 cores out of 8)

---