Nearly 2,000 out of 35,609 - see my Sunday Reports.

Mike

Mike Gibson is trying to track the number of stuck tasks, and I see that he has [re]posted the latest estimate whilst I was preparing an earlier version of this post. It appears to be based on the premise that anything not in a generation currently displaying movement is stuck, which is as good as any other method but assumes that all non-stuck candidates are considered for processing on each sweep (which may or may not be true, depending on the queries used by the work management system...). Without access to the server-side databases and/or knowledge of the queries used we can only estimate, after all :-(

My definition of a "stuck" cell is one where the last WU processed failed in some fashion. Some other folks might define it more simply as "hasn't moved for quite a while" and those may not be identical sets :-), in which case why aren't they moving?...

There are 448 cells that don't get counted in the WCG-provided daily state.txt file but the generations.txt file still refers to the full 35609 cells -- are those stuck or has the ARP1 flow management system just lost track of them for some reason?

There are currently about 710 "Extreme" and "Accelerated" cells according to generations.txt, and all the "lost" cells would appear to be from that set. Of course, we can't be 100% sure whether all those cells regarded as needing faster processing are not being processed because they are stuck or "lost"; some may just be waiting for the work generation mechanism to get round to those categories again (and that may be waiting on WCG looking into why genuinely stuck units are stuck and doing something about it).

We also don't know whether some cells may have been written off permanently. The latest update implied complete final coverage but the "within 12 months" looks extremely unrealistic given that some Extremes are so far behind that it would take at least 100 days for them to get up to "Normal" status, then it would be down to whether WCG can significantly improve the throughput of the 6-day limit jobs (see Mike's weekly summaries for completion estimates). As it is, I suspect that sorting out stalled/lost ARP1 grid cells is, understandably, fairly low on their list of priorities at present...

Cheers - Al.

Al

My stuck units are taken from generations.txt which is the only complete list.

My definition is any units that have not moved in 3 weeks, which has worked except in 1 instance of a late runner, since corrected.

I used the word "stuck" to refer to any not moving for whatever reason.

I am assuming that all 1,965 units still in generations 021 - 145 are stuck plus most of the 13 in generation 146..

My forecast of completion in December is based on movement over the last 5 weeks but qualified by the fact that the oldest stuck units - the ultras - are now 127 generations behind.

Mike

I recognize that. Happens to me, too, sometimes. One trick I've learned is to open a new tab and login there, close it, returning me to the original tab where they would have wanted me to login (but I already did that in the tab that I just closed), then go back one page in history to return to the post in progress.

It worked for me in Firefox 140, YMMV.

Adri

Harking back to bfmorse's rogue Windows task (ARP1_0012850_148, WU 738550711), it would finally appear to be about to get stuck... The first 6 attempts have one No Reply and 5 more or less identical Error reports, so unless the 7th attempt actually succeeds (no odds on that!) it'll have 6 Errors and out...

I'll report the next stage later (if someone else doesn't beat me to it...)

Cheers - Al.