Yeah, that's my Ryzen 5 5600 running 4 ARP and 2 OPN at the same time. ARPs love Ryzens.

There is definitely something amiss with ARP1 validation -- retry jobs issued because of "no reply" or the "not started by deadline" error validate fairly promptly, but tasks where both initial results are returned well within the deadline sit at Pending Validation. Looking at corresponding work unit numbers shows (as one might expect) that the ones validating have much lower WU numbers than the ones that are stalled!

I'm not sure whether this happens because the transitioners are overloaded or because the validator just isn't seeing the higher-numbered units because of the way it picks up results to check. What follows is "informed speculation" (i.e. I've done a code-dive on BOINC code for another project...) but may be way off if WCG/IBM have hacked the core BOINC code of the validators or the transitioner (not a good idea, so probably not the case!)

Note that it is possible to run multiple validators and transitioners, using an algorithm to ensure that each one processes a distinct set of work units; I'd hope WCG does that! The below refers to an individual transitioner or validator...

The validator deals with work units that the transitioner has marked as needing validation, and seems to process them in ascending order of work unit number. The validator will process a certain number of work units and associated results (1000?) then have a brief sleep before starting another batch. Each time it'll tend to pick up the lowest-numbered units, so if more retries have come in during the process interval, higher numbered ones will be missed again... However, the number of ARP1 units processed per day is low enough that getting them through the validator(s) should not be an issue (unless they're sometimes turning validators off to reduce server load...)

This leaves us with the possibility that the transitioner(s) might be suffering a backlog. The normal behaviour of the transitioner is to run through a pre-defined number of work-units then, possibly after a brief pause, start again... Each batch of work units is selected based on when the work-unit was marked for transitioner attention (which could be in the past!), and then [probably] in ascending order of work-unit number within that. It pays no attention to which applications are involved

If there aren't enough transitioners running the sheer volume of the relatively short run-time OPN1/OPNG work might cause issues.

If an official BOINC server expert reads this and can correct it, feel free! And, of course, if there's some other explanation for this issue, I'd love to know what it is; always willing to learn :-)

Cheers - Al.

P.S. I've got some scripts that analyse work unit result behaviour for my own results and their wingmen. If necessary, I can actually provide data on this issue from the viewpoint of a single user :-)

Snap! Just checked and the tasks awaiting validation from a few days ago haven't changed their status.

I just checked my results, and the four ARPs that show up as valid have turn-in dates of today or yesterday. I have a bunch of other ARP units stacked up as well in the "pending validation" status, but I have to assume that some of these got stuck during the early days of the restart. ARP can take quite a while to run, and so it may be a while before they get validated. One of my currently-running units is a _4 with two user aborts, for instance.