The limit sems to be set as a number of tasks per active cpu core and gpgpu, nothing limiting it server side to hours of work. Practically, fast machines are never able to cache up lots of work in computing hours, except for cep2 or when other sciences happento be in a long hours batch cycle.

Yes, 25 per thread. This was imposed, IIRC, for HCMD2 as it was finishing up. Run times were all over the map and otherwise reasonable machines were over-caching. The limit has simply never been removed.

It worked to solve the problem at hand but as we can see it wasn't particularly elegant.

That would then be 'ludicrously' fast, as 25 per core and 10 hours would suggest a speed of 24 minutes per result of fahv and or faah. Barely enough to bridge a bigger maintenance outage. The project average though last 7 days was 2.4 hours, not knowing what the object mean is wcg wants.

Not getting that many for a decent cache could be on a 'hidden' technician agenda of improved return times, lower storage needs, higher server/result status page performance. The deadlines are being worked too with mcm and ugm having 7 days. If your device is sparingly on, just few hours in the weekend, you're not welcome, or could we convince the technicians to give a larger 'per core' allowance? If a device is rated reliable, usually returning all results wihin 48 hours, maybe a 2 tiered 'per active core' could be set, slow and fast, but no, yet another way to destabilize what's working.