Received my last ARP1-task at 2025-03-10T18:49:55 (19 hours ago), while normally I should have about thirty of them in my queues.

Adri

My last _0 or _1 ARP task was at 1857 UTC yesterday. However, I did receive 3 after that were _2 or _3 resend tasks. The last was at 0658 UTC today and I am now dry.

My last MCM was 17:03 so 17 minutes earlier.

My last ARP was yesterday.

Mike

for MCM I'm getting the "Tasks are committed to other platforms" message, so resends going out make sense.

[Edit -- Shortly after I posted this I (finally) started to get a small number of new tasks. Typical "say it's broken, and it'll work again"... I'll leave the rest of the post more or less "as is".]

Trickle's too generous a word, though I'm not sure what indicates even less (an infrequent drip, perhaps?) -- I've seen exactly 1 MCM1 retry in the last 24 hours, and that's across a set of systems that usually returns 650+ MCM1 results a day. No new work at all during that time, so I suspect something is broken [again] regarding new work, as the "let's do retries" periods have usually been less than 6 hours long in the past...

When new MCM work is being released by the feeders the only retries I seem to get are for WUs where a result failed relatively quickly. Retries caused by missed deadline tasks only seem to show up when new work is unavailable for one reason or another!

This effect appears far less likely for ARP1 unless there's a system breakdown of some form; it is probably related to the total amount of tasks available to be fed out (new and retry) and the selection criteria being used by the feeders at their WCG default settings.

I can imagine a scenario where "choose items to feed in increasing WU ID order" might backfire -- consider a situation where a big backlog of retries for a relatively scarce platform has built up, eventually the server-side cache of available tasks supplied by the feeders could all be for that platform... We already see it in moderation even with more common platforms, especially if a lot of retries were spun off at about the same time because oversubscribed hosts missed simultaneous deadlines :-(

And whilst I'm thinking about results that get sent back on the fifth day (or miss the deadline completely), I wonder if the WCG mechanism for deciding how much new work to release takes into account the likelihood that at any time there are a large number of tasks out there on systems that take several days to return them? I mention it because if they throttle the amount of new work based on "in the field" counts that probably works to the detriment of users with small buffers or relatively low profile quotas...

In light of the above, either a lot of us are extremely unlucky about getting work or there has been an issue (deliberate or otherwise) since late afternoon (UTC) on the 11th (and most users have given up on posting about lack of work...). No sign that WCG are aware as at the time of this post [but post-posting events have rendered that irrelevant, of course :-)]

Cheers - Al.