I think you need to look at the Server Status again.
We will be out by morning (in the U.S.). Then, you will see it in the "Tasks Ready to send".

Still 29,843 ready to send as I see it.

I think you need to look at the Server Status again.
We will be out by morning (in the U.S.). Then, you will see it in the "Tasks Ready to send".

The information on the main page has no Ready to send data there.
I suggest you look at the actual Server Status page, which presently shows

Computing status
Work
Tasks ready to send 29843

---

Grant
Darwin NT

As usual I’m guessing, but I’d assume the Tasks ready to send are a buffer that the server maintains from which it can immediately service client requests for new work. If that buffer gets topped up from the Total queued jobs – which is what people are pointing out is getting smaller, and at the current rate will be exhausted before the end of the day – we are indeed about to run out of work. Give it a few more hours, and we’ll find out…

As usual I’m guessing, but I’d assume the Tasks ready to send are a buffer that the server maintains from which it can immediately service client requests for new work. If that buffer gets topped up from the Total queued jobs – which is what people are pointing out is getting smaller, and at the current rate will be exhausted before the end of the day – we are indeed about to run out of work. Give it a few more hours, and we’ll find out…

Yep.
Ready to send should start falling (and not recover) in 6hr 45min or so once Total queued jobs hits 0 (as long as 1 Queued job = 1 Work Unit).

---

Grant
Darwin NT

As usual I’m guessing, but I’d assume the Tasks ready to send are a buffer that the server maintains from which it can immediately service client requests for new work. If that buffer gets topped up from the Total queued jobs – which is what people are pointing out is getting smaller, and at the current rate will be exhausted before the end of the day – we are indeed about to run out of work. Give it a few more hours, and we’ll find out…

You live and learn - thank you :-)

It has been dropping steadily for at least 10 days.

No it hasn't it's been pretty steady for some time now. Still sitting at close to 30,000 Tasks Ready to send.
Since we last ran out of work in June, we haven't come close to running out of work since. The lowest it's been since then has been around 24.5k, and even then it was only for a few hours.

You're looking in the wrong place, the tiny 30,000 (a pitifully small amount since collectively we process 500,000 a day) on server status is not the big picture. The main page tells you the total amount of work to do. That was filled up in mid summer to 15 million, and has fallen steadily to 0.

Looking at server status is like saying we have an excellent supply of goods because you can see the truck coming with another full load. It's irrelevant, you need to look in the warehouse it's coming from. They should put the large number in server status. At least we can see the full story on the main page, most projects don't even tell you what that number is.

---

As usual I’m guessing, but I’d assume the Tasks ready to send are a buffer that the server maintains from which it can immediately service client requests for new work. If that buffer gets topped up from the Total queued jobs – which is what people are pointing out is getting smaller, and at the current rate will be exhausted before the end of the day – we are indeed about to run out of work. Give it a few more hours, and we’ll find out…

You live and learn - thank you :-)

Hopefully we don't get the usual "the world is coming to an end" complaints from half the users saying they have nothing to do and they're going to leave the project in some kind of protest. Go find another project (temporarily, or on lower weighting, etc). Let your computers have a rest. Whatever. The point of this project is to do science. If there's no computing to be done today, it doesn't matter, there are other scientists that need your help too. Boinc has about 30 projects.

---

I hadn't been paying much attention recently, but while restarting my PC that crashed a few days ago I just started refilling my cache - grabbed 17 ok and then that seemed to be the very last of them.
Now actually zero ready to send and nothing being downloaded

---

Hopefully we don't get the usual "the world is coming to an end" complaints from half the users saying they have nothing to do and they're going to leave the project in some kind of protest.

I am much more hopeful than that. They may have learned lessons about AI and don't need us any more.
We could be irrelevant. (Don't worry. Not likely just yet, but possible someday.)

---

Units that bounced back to the server for whatever reason (not started on time, not finished on time etc) will trickle in and out for the next day or so and really clear all the actual work. Given the holiday weekend I'd not expect a proper refill until Tuesday at the earliest. Hopefully I'm wrong on that.

If you have work queued up, might want to up your WU time to 24hrs so they can keep crunching longer until the drought ends.

Looks like you're all ignoring the possibility that some of the work requires multiple workunits, with most of them based on the results from previous workunits and therefore not converted to workunits until those previous workunits are verified. They may have server programs doing that conversion. rather than humans.

Also, there's a trickle of work entered through the Robetta interface from outside Rosetta, and therefore getting workunit names starting with rb_.

Inside the US, many universities are finding that opening normally starts many new cases of COVID-19 on campus, and therefore calls for a quick emptying of the campus.

Also inside the US, it's very close to the Labor Day holiday, so less work is being done than usual.

Many BOINC users have found that it's a good idea to have multiple BOINC projects set up on each computer, so that if one project runs short of workunits, the computer can get additional workunits from another project instead of just sitting idle.

I prefer World Community Grid, especially their Open Pandemics subproject.

https://join.worldcommunitygrid.org?recruiterId=480838

This is mainly for COVID-19 at first.

You should choose settings that allow doing other types of work if the COVID-19 work runs low.

I expect it is the summer lull, since the work has been going steadily down for over two weeks (they did have 15,000,000 jobs back then).
But the more intriguing possibility is that they are changing direction in some fashion, maybe with a new type of work.

I raise that not because it is highly likely, but only to point out that since they don't tell us anything, we are free to guess as we wish.
(But I am ready to bail out to WCG/OPN as needed.)

---

Units that bounced back to the server for whatever reason (not started on time, not finished on time etc) will trickle in and out for the next day or so and really clear all the actual work. Given the holiday weekend I'd not expect a proper refill until Tuesday at the earliest. Hopefully I'm wrong on that.

If you have work queued up, might want to up your WU time to 24hrs so they can keep crunching longer until the drought ends.

How does that work? Does a WU get given to me with 50 things to do, my PC does as many of those 50 as it can in 8 hours, then sends those answers back, then the server puts the uncompleted work back together in new WUs?

And why does Rosetta do it this way when no other project does? I can see the advantage that everyone knows exactly how long something will take, whether they have a fast or a slow computer, but it seems a bit complicated from their end.

---

[snip]

intriguing possibility is that they are changing direction in some fashion, maybe with a new type of work.

If they are changing direction in a way that requires a new version of their application, you'll probably see the new version first in tasks from Ralph@home, the alpha test site for Rosetta@home.

If, instead, the new direction doesn't need a new version of their application, you probably won't see it there unless it uses a section that they don't consider adequately tested.

I hadn't been paying much attention recently, but while restarting my PC that crashed a few days ago I just started refilling my cache - grabbed 17 ok and then that seemed to be the very last of them.
Now actually zero ready to send and nothing being downloaded

I managed one re-send since, but just now have managed to fill my cache on 2 machines.
Not sure if it's a sign of many coming through as all figures still show zero, but dribs and drabs are making an appearance.
Hopefully that gives the project guys a few days extra to get some more regular work available.

---

Units that bounced back to the server for whatever reason (not started on time, not finished on time etc) will trickle in and out for the next day or so and really clear all the actual work. Given the holiday weekend I'd not expect a proper refill until Tuesday at the earliest. Hopefully I'm wrong on that.

If you have work queued up, might want to up your WU time to 24hrs so they can keep crunching longer until the drought ends.

How does that work? Does a WU get given to me with 50 things to do, my PC does as many of those 50 as it can in 8 hours, then sends those answers back, then the server puts the uncompleted work back together in new WUs?

And why does Rosetta do it this way when no other project does? I can see the advantage that everyone knows exactly how long something will take, whether they have a fast or a slow computer, but it seems a bit complicated from their end.

I was referring to WU's as a whole, not what's inside them. Often for whatever reason you will see machines that are (for example) dual core laptops with 96 WU's in their queue. There's no way they are finishing them all in the 3 day window so the WU's get bounced back once the timers run out and they then are sent out to someone else. That's what I was referring to.

Units that bounced back to the server for whatever reason (not started on time, not finished on time etc) will trickle in and out for the next day or so and really clear all the actual work. Given the holiday weekend I'd not expect a proper refill until Tuesday at the earliest. Hopefully I'm wrong on that.

If you have work queued up, might want to up your WU time to 24hrs so they can keep crunching longer until the drought ends.

How does that work? Does a WU get given to me with 50 things to do, my PC does as many of those 50 as it can in 8 hours, then sends those answers back, then the server puts the uncompleted work back together in new WUs?

And why does Rosetta do it this way when no other project does? I can see the advantage that everyone knows exactly how long something will take, whether they have a fast or a slow computer, but it seems a bit complicated from their end.

I was referring to WU's as a whole, not what's inside them. Often for whatever reason you will see machines that are (for example) dual core laptops with 96 WU's in their queue. There's no way they are finishing them all in the 3 day window so the WU's get bounced back once the timers run out and they then are sent out to someone else. That's what I was referring to.

I would rather the Project limit new users to X amount of taskss until Boinc can figure out how long a particular pc can crunch a task and how many it can do in X amount of hours rather than just send it Y amount of tasks right away. That would limit the number of tasks that get returned because the pc can't do them in the alotted amount of time, ie 3 days. Nothing can stop the user that decides to game for 2 days or a pc that crashes or a user that suddently goes out of town and turns it off or even the user that loses power due to storms etc but reducing the resends for new users is a good idea.

[snip]

I would rather the Project limit new users to X amount of taskss until Boinc can figure out how long a particular pc can crunch a task and how many it can do in X amount of hours rather than just send it Y amount of tasks right away. That would limit the number of tasks that get returned because the pc can't do them in the alotted amount of time, ie 3 days. Nothing can stop the user that decides to game for 2 days or a pc that crashes or a user that suddently goes out of town and turns it off or even the user that loses power due to storms etc but reducing the resends for new users is a good idea.

10 or slightly more tasks would be a good value, since it usually takes 10 tasks returned successfully to calculate the speed properly.
Some exceptions for computers that make more than 10 virtual cores available. Issue another task for each task returned before 10 have been returned.

Another good choice would be twice as many tasks as the computer has virtual cores, with one more added for every task that is returned.

[snip]

I would rather the Project limit new users to X amount of taskss until Boinc can figure out how long a particular pc can crunch a task and how many it can do in X amount of hours rather than just send it Y amount of tasks right away. That would limit the number of tasks that get returned because the pc can't do them in the alotted amount of time, ie 3 days. Nothing can stop the user that decides to game for 2 days or a pc that crashes or a user that suddently goes out of town and turns it off or even the user that loses power due to storms etc but reducing the resends for new users is a good idea.

10 or slightly more tasks would be a good value, since it usually takes 10 tasks returned successfully to calculate the speed properly.
Some exceptions for computers that make more than 10 virtual cores available. Issue another task for each task returned before 10 have been returned.

Another good choice would be twice as many tasks as the computer has virtual cores, with one more added for every task that is returned.

Milkyway limits everyone to 300 tasks per GPU (which as they're small tasks is about 3 hours). Not sure why.

---

[snip]

I would rather the Project limit new users to X amount of taskss until Boinc can figure out how long a particular pc can crunch a task and how many it can do in X amount of hours rather than just send it Y amount of tasks right away. That would limit the number of tasks that get returned because the pc can't do them in the alotted amount of time, ie 3 days. Nothing can stop the user that decides to game for 2 days or a pc that crashes or a user that suddently goes out of town and turns it off or even the user that loses power due to storms etc but reducing the resends for new users is a good idea.

10 or slightly more tasks would be a good value, since it usually takes 10 tasks returned successfully to calculate the speed properly.
Some exceptions for computers that make more than 10 virtual cores available. Issue another task for each task returned before 10 have been returned.

Another good choice would be twice as many tasks as the computer has virtual cores, with one more added for every task that is returned.

I like the 2nd idea better as a strict number of tasks means the person bringing a 64 core machine can't even get enough to fill it up once if the number is too small, 3 per core is a good start, 8 hours tasks times 3 tasks equals 24 hours, then let more flow thru as the machine starts returning tasks up to the amount they can return in 3 days. If you want the user to feel like they have enough tasks than 4 or 5 per core would be more than 24 hours of work. I think a short 'Notice' from Rosetta would help people figure out what's going on and why they aren't getting 300 tasks to 'fill their cache'.

On a side note I HATE the default of Boincs 10 day workunit cache settings!!! I would much rather see a 1 or 2 day setting to start with and then let the user up that as they start to figure out what's going on. Sending a brand new user 300 workunits that take 5 hours each on a quad core machine is crazy!!

I think the Team GPUUsersGroup has a Boinc add-on that limits the number of workunits you can get from a project and that would help alot at those projects that just keep endlessly sending workunits even though you have 1/2 day cache settings.