After about a day beyond after the deadline you see in the client, the server will re-issue the work unit you had to someone else to crunch. If you complete the work unit before they get to it then the server will abort it for them and no work is wasted. If they start it, then you finish before they do, they will be allowed to finish as well so they don't have wasted time. However, that means you and they are doing redundant work. If they are quick and finish before you do then you will get a "too late" status and your work won't count for credit or useful work.

Further, ARP has work units that must be done sequentially and so if you're holding onto work units for long periods that will delay the completion of the overall project. If you have a device that is consistently unable to meet the deadline it is best to exclude it. Given the importance of timing for ARP, the length of time required for each work unit, and the heavy memory/cache load required, I consider it to be more of a "hardcore" project that really benefits from newer devices running 24/7.

Just to expand Acibant's 2nd paragraph, a unit cannot move on to the next generation until it has been vaidated so it needs 2 results returned before that happens.

The other reason for slow units is if crunchers have too large a cache waiting to start. There is no need to hold more than 1 queuing and if you take more than 2 days, you should not hold any spare. The units are readily available, but not necessarily immediately.

Slow machines also delay faster machines from receiving their credits.

Mike