MarkH

That unit will be a re-send. The original would have been distributed on or about 9 June.

July is supposed to be the end of some upgrades, but judging from the latest output, they may have completed it already!

Mike

Despite nothing being sent out, we still managed nearly 3,000 units validated in the day.

Mike

Only one retry for me since the dearth set in. I typically finish Linux tasks in 4.25hours. Unless in a VM on the same machine when they take about an hour longer. Windows tasks for ARP in a VM on the same physical machine take more like 6.5 hours. And while typing I have had one _0ARP task and one _0MCM arrive. I was alerted by my fans starting up.

Unixchick

Good luck with that one. You are probably it's last hope.

Mike

[Might as well have some forum time while "Another scheduler is running for this host" ]

One thing I noticed when I checked to see how this one was getting on was that all the ones running on the 24.05 O/S that went Invalid had an elapsed time quite a lot longer than the CPU time used, so I had a quick look at the stderr.txt content for each of them to see if there was anything obvious[*1] such as evidence of suspension or actual restarts. One of them (_5) had an actual restart after one checkpoint; the others didn't seem to have any large-scale interruptions, so that wasn't particularly useful this time

I don't know how BOINC measures elapsed time on Darwin systems, so it may be that it counts all the time the program isn't actually suspended; I also don't know what happens if the user has asked for less than 100% of CPU processor time, so that may distort the numbers as well.

Without being able to find out a lot more about the individual systems (most of which we would only know if the users actually posted about it...), I don't think this is likely to be resolved. I wonder how many other Darwin tasks suffer the same fate but we never find out. (Come to that, do we have any idea as to how many ARP1 WUs go to Darwin users?)

Cheers - Al

*1 If an ARP1 task gets suspended frequently because BOINC thinks the system is busy, or BOINC wants to let other tasks have a go, it can [usually] be spotted because the system timestamps in the stderr log will be spaced [far] further apart than the elapsed time would suggest. The same applies if the whole system suspends or hibernates regularly. For instance, i saw one task that had CPU and elapsed times well under 24 hours but the log showed two transitions through midnight -- that, admittedly, was an extreme example!