I recently came across a cute problem at Public Services and Procurement Canada while working on queue performance issues. Imagine a work environment where servers experience some kind of random interruption that prevents them from continuously working on a task. We’ve all been there—you’re trying to finish important work but you get interrupted by an urgent email or phone call. How can we manage this work environment? What are the possible trade-offs? Should we try to arrange for infrequent but long interruptions or should we aim for frequent but short interruptions?

Let’s rephrase the problem generically in terms of machines. Suppose that a machine processes a job in a random run-time, , with mean and variance , but with an otherwise general distribution. The machine fails with independent and identical exponentially distributed inter-arrival times. The mean time between failures is . When the machine is down from failure, it takes a random amount of time, , to repair. The machine failure interrupts a job in progress and, once repaired, the machine continues the incomplete job from the point of the interruption. The repair time distribution has mean and variance but is otherwise general. The question is: What is the mean and variance of the total processing time? The solution is a bit of fun.

The time to complete a job, , is the sum of the (random) run-time, , plus the sum of repair times (if any). That is,

where is the random number of failures that occur during the run-time. First, condition on a run-time of and thus,

Now, since is the number of failures by time with exponentially distributed failures, this is a Poisson counting process:

By the law of iterated expectations, , and so,

which gives us the mean time to process a job. Notice that in the limit that , we recover the expected result that the mean processing time is just .

To derive the variance, recall the law of total variance,

From the conditional expectation calculation, we have

We need . For fixed , we use the Laplace transform of the sum of the random repair times, , that is,

where is the Laplace transform of the unspecified repair time distribution. The second moment is,

We have the moment and variance relationships and , and thus,

The law of total variance gives the desired result,

Notice that the equation for the total variance makes sense in the limit; the processing time variance becomes the run-time variance. The equation also has the expected ingredients by depending on both the run-time and repair time variance. But the equation also has a bit of a surprise, it depends on the square of the mean repair time, . That dependence leads to an interesting trade-off.

Imagine that we have a setup with fixed , , and , and fixed but we are free to choose and . That is, for a given mean total processing time, we can choose between a machine that fails frequently with short repair times or we can choose a machine that fails infrequently but with long repair times. Which one would we like, and does it matter since either choice leads to the same mean total processing time? At fixed we must have,

for some constant . But since the variance of the total processing time depends on , different choices of will lead to different total variance. The graph shows different iso-contours of constant mean total processing time in the total variance/mean time between failure plane. Along the black curve, we see that as the mean total processing time increases, we can minimize the variance by choosing a configuration where the machine fails often but with short repair times.

Why is this important? Well, in a queue, all else remaining equal, increasing server variance increases the expected queue length. So, in a workflow, if we have to live with interruptions, for the same mean processing time, it’s better to live with frequent short interruptions rather than infrequent long interruptions. The exact trade-offs depend on the details of the problem, but this observation is something that all government data scientists who are focused on improving operations should keep in the back of their mind.