World Community Grid - View Thread - High Priority Lockout

The reason for the use of reliable work is that we receive groups of data in batches from the researchers. For many reasons, this is the fundamental unit of data transfer between us and them. Within each batch, the strong majority of workunits finish quite quickly - within 2-3 days of them being sent out. However, there are a few stragglers that prevent the batch as a whole from being completed. Without the 'reliable' mechanism in place, these stragglers were taking weeks to complete and thus delaying completing batches. Depending on the particular project, having more batches in progress at the same time consumes significantly more storage and increases the size of the database. These have both caused us issues on the backend in the past. With the reliable mechanism in place, batches finish about 1.5*deadline. Without it, they were taking 3-4*deadline.

I work as a real time programmer that has to contend with data flow problems so I knew the reason why priority processing was being triggered in repair work units before this was posted. I can agree with the idea of sending repair units to systems with short turn around times. I only object to the short deadline because it could cause other records to be late and force the creation of more repair units. In my case I receive so many repair units that it force my queue to move close to the deadline. Which is better? Process one repair unit a little slow or create a bunch of repair units by giving repair units priority.
The fact that people figured out that a longer queue would avoid this problem indicates that others have had the problem and worked around it. In distributive processing your best bet is to give important work to reliable processors but you shouldn't try to take over their computer.