i have noticed that for say an 8th gen Intel box, 6 core, it won't queue more than about 24 work units at a time despite having my queue settings maxxed out in BOINC at 10 days in both fields. Each work unit usually takes less than 2 hours some less than 1 hour. Is this a bug or perhaps my BOINC clients are confused by Rosetta occasionally sending a few work units out so it is holding off on queuing up SiDock?

There are a couple of obvious possibilities.

1: The project does not have work to hand out right now.
2. If any task is in any danger of not being returned on time, BOINC will not fetch new tasks. This depends on settings and usage history.

Thank you.
1. SiDock does consistently have work "Tasks ready to send 22058" right now on server status page.
2. Deadline for SiDock work unit is at least 3 days after receiving so that's not the issue since the work units don't take long to compute.
My settings BOINC settings are maxxed out and my machines do nothing but BOINC 24/7. Also the settings on my online SiDock profile is maxxed out
Store at least 10 days of work
Store up to an additional 10 days of work
Switch between tasks every 120 minutes
Request tasks to checkpoint at most every 60 second

Hmmm.

Seriously in all my 50+ machines, if i unplug a WIFI stick, it stops crunching within 3 hours despite 10 days 10 days set locally and also server side.

i have noticed that for say an 8th gen Intel box, 6 core, it won't queue more than about 24 work units at a time despite having my queue settings maxxed out in BOINC at 10 days in both fields.

There is a limit, based on the number of cores you have. I am not quite sure what it is, but I have never gotten more than a day's work either on any of my machines (currently a Ryzen 5950X).

Hi folks!

Yes, it's a server limit. Very useful for some purposes (within the existing infrastructure). But you can get around it by using ncpus tag in cc_config.xml during task request.

Thank you for participation!

Thank you, I will try to find that file. Could you say why that limit is in place when the deadline for work units is multiple days out?

Thanks, could you say why that severe limit is in place when the deadline shown in the client is multiple days? The file does not seem to exist anywhere so I gather I create the file with only that tag within the SiDock directory. Correct format? I need because i am waiting on some WIFI sticks and would like to lessen the frequency of walking to the internet-less machines with a WIFI stick.
cc_config.xml
<cc_config>
<options>
<ncpus>15</ncpus>
</options>
</cc_config>

Hi! Уour cc_config.xml file is correct! "Short tasks queue" on participant computers reduce a time that need for completion of whole tasks set (and any subsets within it). Of course, first of all it is useful for large tasks (when for each tasks a hours of CPU time is needed).
But if tasks became short, drastic increase of number of workunits in "In Progress" state will "inflate" a project database and server work more "heavy".

Thank you i see what you mean. Many of the work unit groups can be crunched by the community in a week or so I have noticed and you run a tight ship. One group gets to about 98% and then the next group begins to have results sent in and within a few days later the first group is completed no gaps in completion. Enabling larger queues would increase server load by computers not using as large % of the work units given to them 4 whatever reason and more needing to reissued.
Is it possible to get a list of future groups to be crunched on the site? Is there an 'end' to this stage of research where the community has completed all work 4 Covid?

I should note that even though you have a server side limit of work units sent for a given estimate computational power of a computer, that does not mean you will have a same-day turnaround. If the user has multiple projects going they could have a significant queue to crunch through before resuming SiDock, depending on BOINC % resource allocation settings and luck. But the proof is in the pudding, err Project Status work unit group completions.

At the beginning, we followed the list of targets (groups of work units) that was published in the presentation. Today, new targets are selected following the intermediate computational results and new scientific data. For instance, the target PLpro was investigated 4 times instead of 2 planned initially. This is why it is difficult to publish a planned list in advance.

If I recall correctly, BOINC assumes that when you ask for 10 days worth of tasks that the computer will be disconnected from the internet for 10 days, and that any task with a deadline within that time is in danger of not meeting its deadline.

Minor correction:

Store at least X days - means that the computer coule be disconnected for up to that long.
Store up to an additional Y days. Means that it is OK to store more on the computer, but not required.