I see I got a rash of _2and _3's. I looked through them and most of them were the result of an error. There was a couple of "no reply" and a couple of "server aborted" ones. The "server aborted" ones were when somebody ran past the time limit but did finish the unit before my system had a chance to start the unit. So on these, there was no time accrued by my system, but somebody else probably has a queue which is just full enough to miss a deadline, but not by much.
With the disparities in the times of the units between the LOO and NFCV types, I can understand why BOINC would overload a queue. If the system got mostly the shorter units for while the queue size would accumulate enough to satisfy the parameters set by the user. When a group of the longer running units came into the queue, the amount of work to be done could almost double, resulting in some missed deadlines.
A possible solution to this could be to separate the two types and allow the user to specify which type they would like to have. This would provide more uniformity in the run times and virtually eliminate the problem of inadvertent overloaded queues.
Another possible solution would be to tweak the units to have more uniformity in runtimes between the two types. But that would probably involve re-writing some code so it might not be worth it.
At any rate, as long as the systems don't waste any time on running some extra units when they are unnecessary, maybe nothing further needs to be done.

Cheers

If you always return work well before deadlines your queue sizes aren't excessive :-) -- I was thinking of systems that (for one reason or another) have queue sizes that don't leave much scope for issues such as (unplanned?) client down-time, tasks that take a lot longer than expected, or other reasons that a client struggles with deadlines.

For what it's worth, I also run about 16 hours on my largest machines (which aren't exactly powerhouses...) and much lower on my laptop and other "smaller" systems which don't ever run bigger tasks such as WCG's ARP1. Limits are tuned to try to ensure I always return WCG stuff within 24 hours of receipt (unless there's a system problem), so the ability to tune download quantities via the profile is a blessing!

As for re-send data, if one only wants the occasional information it's all in the results section of the web site, but there's a lot of [tedious] clicking involved! So some users make use of a WCG-provided API to collect information about individual tasks they have processed.

There was a version of the API from before the web-site overhaul, but it was not very flexible. With the web-site changes came a newer API which allows collection of work-unit data as well as information about one's own results (akin to what the web site provides), so it's possible to see which wingmen failed and why...

I've got some Python scripts that do this, specific to my needs. User adriverhoef has a useful general application (which may or may not be Linux only - not sure about that). There are various other ways of getting at the information, including a web-page based trial interface to the new API. I found out what I needed to know by forum searches (much to my surprise!), but I suspect that trying to describe it in full detail would run over some limit on message size :-)

Cheers - Al.

As to queue sizes:
YOU, are absolutely correct!

But, when the WU is returned MORE than six (6) days after the original WU was received by that volunteer's system and THEIR processing time is LESS than two (2) hours, Wouldn't you agree that their queue size IS EXCESSIVE?

BobbyB wrote:
One way is to go to Results, press the End-key, set the 'Items per page' to a large enough number, scroll through the results, find the beginning and end of a certain pattern that you are looking for, select all those lines, copy and paste them to a line counter program (such as 'wc' on Linux) and presto!

Another way, as alanb1951 replied:
It is Linux only — its homepage begins with "This is software for Linux" — and that makes it easier to maintain.

Using wcgstats from that software package to carry out this task involves some knowledge about the commandline and what files are used. (...) I did this:

$ wcgstats -w*MCM1_......._...._3 -S
* Let's try to locate the workunit.
There are 2283 pages of results available.
>>> Too many matches.  Only one result allowed.

* Showing page 1/2283 of all tasks with status ’0’ on all of your devices:
 <1>   MCM1_0194946_4842_0  Linux Ubuntu  In Progress           2023-01-16T14:13:01  2023-01-22T14:13:01
 <1> * MCM1_0194946_4842_1  Fedora Linux  In Progress           2023-01-16T14:13:06  2023-01-22T14:13:06


- Did this show the desired workunit? [Y (yes)/n (no, next)/p (previous)/l (last)/q (quit)/c (change)/= (match)/PAGENUMBER] 

At this point I typed ^Z to suspend wcgstats temporarily. Then I located the temporary files used by wcgstats in this session:

$ ls -t /tmp/wcgstats.* | head -6
/tmp/wcgstats.225955.wingmen.2023-01-16T20:15:03.247450540
/tmp/wcgstats.225955.results.2023-01-16T20:15:03
/tmp/wcgstats.225955.elected.2023-01-16T20:15:03
/tmp/wcgstats.225955.entries.2023-01-16T20:15:03
/tmp/wcgstats.225955.webpage.2023-01-16T20:15:03
/tmp/wcgstats.225955.cookies.2023-01-16T20:15:03

The needed file is the one with ".entries." in its name. Then I used 'less -N' to scroll through the file with linenumbers, searched for "_2<TAB>" (three characters) to find the first occurrence, noted the linenumber, searched for "_[01]<TAB>" (6 characters), noted the linenumber; then subtracted the two linenumbers and the answer was 121.

Tn-Grid

Follow the instructions on their front page: create an account first.