Industrial Engineering DISCUSSION

M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

Started by lamesgin queuing theoryM/M/1 queueutilisationwaiting timeserver pooling
5 replies 248 views 6 participants
Latest activity · 30 Sep 2026

M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

lamesgin Industrial Engineering Forum
#1

An inspection station in our plant receives jobs at an average of 8 per hour and can process 10 per hour on average, so it is only 80 percent loaded. Yet there is nearly always a queue, and when arrivals went up to 9 per hour for a week the waiting time roughly doubled.

How does queuing theory explain a queue at a station with spare capacity, what are the formulas, and would a second inspector be worth it?

Community replies 5

Re: M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

#2

The queue comes from variability, not from lack of average capacity. Jobs arrive in clumps and service times vary, so there are periods when work arrives faster than it is processed, and the idle time in the quiet periods cannot be saved up for later. The busier the server, the less idle time there is to recover from each clump.

The standard model with random (Poisson) arrivals at rate λ and exponential service at rate µ is M/M/1. Utilisation ρ = λ / µ = 0.8. Average number in the system L = ρ / (1 - ρ) = 4 jobs, and in the queue Lq = ρ² / (1 - ρ) = 3.2 jobs.

Re: M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

#3

Times follow from the same model. Average time in the system W = 1 / (µ - λ) = 1 / 2 hour = 30 minutes, and average wait before service Wq = ρ / (µ - λ) = 0.4 hour = 24 minutes, against a service time of only 6 minutes.

Now raise arrivals to 9 per hour: ρ = 0.9, Wq = 0.9 / 1 = 54 minutes, and at 9.5 per hour it is 0.95 / 0.5 = 114 minutes. The factor 1 / (1 - ρ) is what explodes: the last few percent of utilisation cost far more waiting than the first eighty. Your observation that the wait roughly doubled for a 12 percent rise in arrivals is what the formula predicts.

Re: M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

#4

A second inspector changes the picture out of proportion to the capacity added. For two servers sharing one queue (M/M/2) with the same λ = 8 and µ = 10 each, utilisation per server is 0.4 and Lq = 2ρ³ / (1 - ρ²) = 2 × 0.064 / 0.84 = 0.15 jobs. Wq = Lq / λ = 0.019 hour, a little over 1 minute instead of 24.

Whether that is worth a second person depends on the cost of jobs waiting compared with the cost of an inspector who is idle 60 percent of the time. A part-time or on-call second server when the queue exceeds a set length is a common compromise.

Re: M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

#5

Reducing variability is the other lever, and it costs no capacity. An approximation for a general single-server queue (Kingman's formula) is Wq = ρ / (1 - ρ) × (ca² + cs²) / 2 × mean service time, approximately, where ca and cs are the coefficients of variation of inter-arrival and service times. M/M/1 has both equal to 1. If service times were constant (cs = 0) the wait would halve, to 12 minutes in your case; if arrivals were also scheduled evenly, it would almost disappear.

So levelling the release of jobs to the station and standardising the inspection work both shorten the queue without adding anyone.

Re: M/M/1 queue: why does waiting time explode as utilisation approaches 100 percent?

#6

Before relying on the numbers, check the assumptions against data. Record arrival times and service times for a few days and compute the means and coefficients of variation. Real stations often have batch arrivals, which is worse than Poisson, or breakdowns, which act like very long service times. The formulas are also steady-state averages: they assume ρ below 1 and a long run, and they say nothing about the shift start-up or a temporary overload.

When the system has priorities, rework loops or shared operators, a discrete-event simulation is the usual next step.

TEP COMMUNITY