Not on a 128 thread machine it isn't. I vote 'NO' on limits. There should be as few limits as possible imposed on those who wish to contribute. The only limits should be those that prevent a runaway situation like downloading 1000s of work units only to have them error out immediately. WCG controls the infrastructure and the researchers control the science and if they aren't complaining, let the contributors have all they want. I can run 128 ARP concurrently and they all return in less than 40 hours which is reasonable. Just because it isn't "optimal" in someone's opinion doesn't make it unusable to science. Each member can decide to run each project on their hardware as they see fit but they shouldn't dictate how others contribute on their hardware. Leave the 'UNLIMITED' option.

On 128 or 256 thread machines, even the cache setting is becoming irrelevant. A one or two day cache results in the client hitting the 1000 work unit limit long before hitting the cache limit.

1) The default in the device profile is unlimited at science level
2) There's an overarching rule to not assign more than 70 or 75 work units per core to a device, so effectively like 560-600 is the limit an 8 core device can have, if all are allowed to crunch.
3) Over-overarching is 1000 WU for a device no matter how large the core count. A 64 thread machine doing SCC will run out fast.

Short for, total runaway is not possible, but for the occasion where due reporting and requesting timing sometimes a device manages to get a little more than 1000.

You are seeing the outages at the server end. I would guess that outages (at least the offline ones) are greater at the client end.

Now that 037s are flowing it means we are over 20% at 20.2% complete, based on the current assumption of 183 generations, once we have returned more 037s than there are under, incomplete.

Mike

Assuming that there will be 183 iterations and averaging the last 10 intervals, completion of the project could be about March 2023.

Mike