One of my crunchboxes has 4+ ARP1 tasks and is crunching along. Another crunchbox got 1 task recently. That's neat. Plugging along into Generation 147.

MCM is flowing well.

Looks like they've increased the flow of ARP.

I'm happy to have 2 ARP going at all times now. I don't have a full cache (1 day), but I have enough to keep my machine busy. I'll consider allowing more to run simultaneously if I get a longer queue.

bfmorse.

With MCM1 (and, I fear, MAM1 when it goes live) there isn't a lot that users hit by this can do about it. It's only truly expensive if one runs such a small buffer that one frequently runs out of work, requiring the re-download of the MCM1 master data file; otherwise it's just an annoyance as the job control file is very small. (Of course, ARP1 is a different matter; see later...)

For comparison, I typically handle 700 or so MCM1 tasks a day across 4 systems (none of which have a cache of more than 0.6 days, and tend to see an average of 4 or 5 Server Aborted each day... I can live with that :-)

I suspect this was far less common in the days before the IBM->Krembil migration, because of a server-side feature that was disabled when they tried to clear out all the pending work before the move. This is the concept of a "grace period" as an extension to the due time that isn't reported to the client (so late, unstarted, tasks should still error out as "Not Started by Deadline") but it would allow some extra time before the retries went out for No Reply tasks. I'd be happy to see the return of grace periods for some projects, but only if combined with reduced deadlines -- in this day and age, a 6 day deadline seems a tad excessive for something like MCM1!...

Not all the late returning results are going to be because of excess caching, by the way.

• There are [non-WCG] projects out there that consistently mis-estimate the amount of time their tasks will take. For instance, MilkyWay often underrestimates by orders of magnitude for some tasks then massively overestimates for others, causing all sorts of scheduling issues! And yes, I mean orders of magnitude - e.g. estimate 10 minutes, actual over 24 hours; estimate 6 hours, actual 15 minutes!...
  
• There are users out there that don't make allowance for the time their systems are turned off or tasks are suspended because BOINC thinks the system is busy
  
• There are users who might make those allowances but don't use "Leave applications in memory so if they run multiple projects a lot of tasks will keep winding back to previous checkpoints!
  

There are, of course, less "excusable" reasons why tasks arrive late...)

I have actually had an ARP1 task Server Aborted because an original wingman clocked in late; that doesn't happen very often, because I tend to be able to start new ARP1 tasks almost at once (and often return the retry before a late returner does!) but on this occasion the receiving host was already at its max_concurrent limit... When I looked at the stderr.txt for that task, it turned out that the wall-clock times for the checkpoints included two transitions past midnight; as the total CPU and elapsed times were both comfortably under 24 hours, that indicated either a lot of swapping between different BOINC tasks or use of system suspend/hibernation (but at least LAIM seemed to have been active if it was for the former reason!) -- stuff happens :-)

Cheers - Al.

P.S. during the initial MAM1 Beta testing I got so swamped with Beta tasks (some of them very long-running) that I had to micro-manage my systems to make sure I returned non-Beta tasks far enough before deadline for my satisfaction. Without the aforementioned grace periods, any late return (accidental or otherwise) would [of course] tee up a retry, which I always try to avoid... Hopefully the next Betas won't need as much run time and shouldn't cause so much trouble :-)

I tend to agree that the issues with missed deadlines are far more common on the Windows side; I've even had MCM1 retries where two initial Windows wingmen missed the deadlines with an Error (WCG doesn't explicitly identify "Not Started by Deadline", but it's very recognisable!) and because the retries were teed up at the same time and there were no active tasks Linux got them and polished them off!

I suspect there are a higher proportion of "fire and forget" configurations on Windows systems, as it requires a little more effort to set up BOINC properly on some Linux flavours... The obvious effects will be seen within the WIndows user community -- those of us on Linux are more likely to notice when we can't get work because "tasks are committed to other platforms" (which I believe is usually associated with mass distribution of retries...)

Not all Linux users have workstation or server grade kit, of course -- for instance, I'm running an old i7-7700K (mostly useful as a GPU platform), two Ryzen-based mini-PCs and a Ryzen 7900 :-) However, the comment about technical knowledge certainly applies, as I spend quite a bit of time on a new system working out what I think is an acceptable workload; I "re-tune" systems whenever the application mix changes (e.g. when MCM1 switches targets) and have different app_config files for when Beta tasks are available or if ARP1 has another hiatus!

I've just had a quick look at the data for tasks I processed that were due during May 2025 using my "wingmen" database for MCM1 (in which I keep basic information about every WU processed, both for my task and those of wingmen...)...

I processed tasks for 18433 WUs. 1333 of the WUs had at least one retry, 1093 of them with a missed deadline task. 796 of my tasks were successful retries (many of them for reasons other than missed deadlines!) and 75 were Server Aborted. 60 of the SA tasks were on systems which wouldn't necessarily have got round to the retries for several hours; if I ran (say) a 0.2 day buffer instead of the 0.6 day buffer I typically use, I'd hardly see any Server Aborts but I'd probably end up running more redundant tasks!

Amongst the wingmen tasks were 744 that never returned (NSD, No Reply or Too Late) and 41 that ended up Server Aborted. 186 WUs ended up with 3 valid results!

Those numbers (6% of WUs having a missed deadline, 15+% of missed deadline tasks returning late and 9..10% of my retries being Server Aborted) seem fairly consistent (unless there's a server outage that backs work up!)

Cheers - Al.

P.S. I haven't used Windows for BOINC since before I retired (so nearly 20 years now!); I like systems that could run GPU work without my having to be logged in, and which don't update without my permission. I suspect I could've hammered Windows into submission, but I couldn't be bothered (and I'm not afraid of the command line...)

The MCM flow is more consistent, like Al says. I've also noticed ARP having a similar pattern of resends only during certain periods and then going back to fresh WUs.

I don't think the return time length of ARP matters much as long as we have restricted flow. There is no need to rush completion of a WU only to have it sit a while before being sent out again.
Once we go to an all available ARPs are out, then the length completion time might be an issue, but we need to balance project completion with involving as many people as possible.