We keep seeing the "millions" of jobs in queue, but yet when you look at Robetta, What of those jobs have we seen already via the "completed" work and what tags can we look at to tell what is future work?

Is python stuff included in there? If so under what target name?

We keep seeing the "millions" of jobs in queue, but yet when you look at Robetta, What of those jobs have we seen already via the "completed" work and what tags can we look at to tell what is future work?

Is python stuff included in there? If so under what target name?

I found stuff with RoseTTAFold which is the neural network.
So not all of the millions are for us.
It appears the only way to find out what is for us and for the neural network is to look at each job ID

RoseTTAFold jobs don't get queued at Rosetta@home since they aren't meant for Rosetta@home. I think that if they did, we'd know just from looking at the queue - with all the RoseTTAFold jobs being submitted to Robetta, I doubt we'd have 100,000 left on the queue like we did some weeks ago or so.
The Pythons come directly from the Rosetta@home/IPD team so they don't come from Robetta, which is for scientists around the world to use.

Yes, that is probably the only way to find out if there is work coming to us.
Then again, sometimes I receive Robetta work which I can't find using the ID at the Robetta page.

The 4.20 tasks should last a few days I guess.

---

RoseTTAFold jobs don't get queued at Rosetta@home since they aren't meant for Rosetta@home. I think that if they did, we'd know just from looking at the queue - with all the RoseTTAFold jobs being submitted to Robetta, I doubt we'd have 100,000 left on the queue like we did some weeks ago or so.
The Pythons come directly from the Rosetta@home/IPD team so they don't come from Robetta, which is for scientists around the world to use.

Yes, that is probably the only way to find out if there is work coming to us.
Then again, sometimes I receive Robetta work which I can't find using the ID at the Robetta page.

The 4.20 tasks should last a few days I guess.

Which just goes to show I was right a long time back. We are getting leftovers and things that can't be done on the AI.
Which is pretty much following TAC's way of using BOINC.
Oh well, i crunch what comes. RAH is not my highest priority any more.

4.2 her2 tasks are something that is important to me.
Deals with breast cancer.
My wife had a hormonal tumor.
Not sure if her deals with that kind of tumor, but her grandmother had breast cancer as well.
So nice to see something related to that.

I am finally after all these years beginning to understand all that gibberish in the task names.

4.2 her2 tasks are something that is important to me.
Deals with breast cancer.
My wife had a hormonal tumor.
Not sure if her deals with that kind of tumor, but her grandmother had breast cancer as well.
So nice to see something related to that.

I am finally after all these years beginning to understand all that gibberish in the task names.

I am sorry to hear that.
And yes, looking at the task names, there is usually a good chance that we can figure out what it is about just by using a search engine.

---

4.2 her2 tasks are something that is important to me.
Deals with breast cancer.
My wife had a hormonal tumor.
Not sure if her deals with that kind of tumor, but her grandmother had breast cancer as well.
So nice to see something related to that.

I am finally after all these years beginning to understand all that gibberish in the task names.

I am sorry to hear that.
And yes, looking at the task names, there is usually a good chance that we can figure out what it is about just by using a search engine.

At first I figured it was some sort of random secret code and never bothered with it. Finally decided after all these years to look at it after gaining some insight based on Robetta protein strings.

I think there are still a plenty of work for regular Rosetta in queue.
And work shortage is just another example of misconfiguration and poor maintenance of the project tech staf (admins/programmers).

Looks like work generator daemons configured to maintain about 5000 tasks in ready to sent state (taking it from the large work queue displayed on the home page when needed), but this target set as combined number.
Ignoring the fact that the project now has two fundamentally different types of tasks that are not mixed with each other.

There are two separate work generators. One creates regular Rosetta WUs only and second is creating Python vBOX WUs only.
You can see them on server status page: https://boinc.bakerlab.org/rosetta/server_status.php
rah_make_work_rosetta - regular WUs generator
rah_make_work_rosetta_python_projects - Python WUs generator

Pythons WUs processed by volunteer computer at much lower pace (due to much higher system requirements, absence of vBox on some of BOINC client installation, some users do NOT want vBOX tasks and disabled it, etc)
This cause current work cache (Tasks ready to send) after some time end up occupied by vBox python WUs only and no any tasks for regular Rosetta available to download.
But regular WUs genenator does not kick in because target work cache size is already filled (by Python tasks) and produce new work only after some Pyton tasks distributed to clients "freeing up space" for regular tasks.

So now regular rosetta performance and work supply is limited by performance of much slower Python work queue.

P.S.

I saw messages in other topic about that project is simply run out of all regular (4.20) Rosetta WUs and all few millions WUs in main work queue is Python tasks only.
But I see that is not the point. New regular WUs continue to be created and distributed every day by server, only sometimes at a greatly reduced pace (you need to be a lucky one to get some, but it still possible).
And after monitoring the server status, it looks like this pace is limited by the factors that I described in the previous post.

P.S.

I saw messages in other topic about that project is simply run out of all regular (4.20) Rosetta WUs and all few millions WUs in main work queue is Python tasks only.
But I see that is not the point. New regular WUs continue to be created and distributed every day by server, only sometimes at a greatly reduced pace (you need to be a lucky one to get some, but it still possible).
And after monitoring the server status, it looks like this pace is limited by the factors that I described in the previous post.

No (and that applies to all of your previous post as well).
Some Rosetta 4.20 work is occasionally submitted- those are the rb Tasks.
For the usual Rosetta 4.30 Tasks, the project needs to load up those Tasks. Since that hasn't happened, there is only the occasional resend or rb Task available for Rosetta 4.20 work.
All the current Total queued jobs are Python Tasks, as is shown on the Server status page.

---

Grant
Darwin NT

Looks like work generator daemons configured to maintain about 5000 tasks in ready to sent state (taking it from the large work queue displayed on the home page when needed), but this target set as combined number.
Ignoring the fact that the project now has two fundamentally different types of tasks that are not mixed with each other.


There are two separate limits in play, 5,000 for the Python tasks and 33,000 for the 4.20 tasks. When there are 4.20 tasks available they are fed into the queue independently of the Python tasks.

Looks like work generator daemons configured to maintain about 5000 tasks in ready to sent state (taking it from the large work queue displayed on the home page when needed), but this target set as combined number.
Ignoring the fact that the project now has two fundamentally different types of tasks that are not mixed with each other.


There are two separate limits in play, 5,000 for the Python tasks and 33,000 for the 4.20 tasks. When there are 4.20 tasks available they are fed into the queue independently of the Python tasks.

My understanding is that that queue gets drained quite quickly, especially after a bit of a task-drought, and the buffer only gets refilled once every 6(?) hours. Maybe the project need to reduce that number down to 1 or 2 hours... Anyone have any experience of the server setting options and limitations?

---

My understanding is that that queue gets drained quite quickly, especially after a bit of a task-drought, and the buffer only gets refilled once every 6(?) hours.

Nope, it gets filled as it empties.
However the period between updates of the various stats is not only different for different values, but it's also very lengthy- several hours in some cases.

There can be times where it might show some Tasks still available, but you're not able to get any because there aren't actually any to be had. And there can be periods where it shows no Tasks available, even though you're able to get work, it's just that the Server status page hasn't yet updated to show that new work as been loaded up.

---

Grant
Darwin NT

My understanding is that that queue gets drained quite quickly, especially after a bit of a task-drought, and the buffer only gets refilled once every 6(?) hours.

Nope, it gets filled as it empties.
However the period between updates of the various stats is not only different for different values, but it's also very lengthy- several hours in some cases.

There can be times where it might show some Tasks still available, but you're not able to get any because there aren't actually any to be had. And there can be periods where it shows no Tasks available, even though you're able to get work, it's just that the Server status page hasn't yet updated to show that new work as been loaded up.

Understood - thanks for that.

---