Queueing Theory Simulator (M/M/1)

arrival/service rates and queue stability

Loading interactive simulation...

the rho cliff 🖖

L = ρ/(1−ρ) doesn't grow smoothly — it has a vertical asymptote at ρ = 1, so as utilization creeps from 90% to 99% the average queue length jumps from 9 people to 99, and right at capacity it's unbounded. That's the 'rho cliff': a queue at 80% utilization feels almost identical to one at 85%, but push it to 95% and wait times balloon, because W = 1/(μ−λ) has the same singularity — the denominator is shrinking toward zero, not the numerator growing. It's why real systems like call centers and hospital ERs are deliberately overprovisioned well below 100% capacity: that 'wasted' idle headroom near the top is what keeps you off the cliff.

randomness is what builds the line 🖖

In M/M/1 the two M's stand for "Markovian": arrivals come at random (Poisson) and service times vary at random (exponential), through a single server. The core idea is surprising — a queue can build even when the server is on average faster than customers arrive. If everyone showed up like clockwork and every job took the same time, a server with spare capacity would never form a line. Waiting comes from variability, not from overload. Set λ well below μ and a line still flickers in and out.

Little's Law asks for almost nothing 🖖

The L and W shown here are not independent: they satisfy L = λW, and likewise Lq = λWq. That identity assumes almost nothing. John Little proved in 1961 that it holds for any stable queue in steady state, whatever the arrival or service distributions, however many servers, and in whatever order customers are served. The same relation governs a hospital ward, a factory's work-in-progress and a store's inventory: average contents equal arrival rate times average time spent inside.

Problem solved in full

  1. A queue with 3 arrivals an hour and a 20% rise 5 steps

    Customers arrive at 3 an hour and the server handles 4 an hour. The server is idle a quarter of the time, which sounds comfortable. Work out the queue that produces — and then what a 20% rise in arrivals does to it.

    1. The chain balances: the rate into each state equals the rate out, which gives Pₙ = (1 − ρ)ρⁿ — a geometric distribution over queue length, with ρ the fraction of time the server is busy. Here ρ = 0.75.

    2. The mean of that distribution is ρ/(1 − ρ). Look at what is in the denominator: not the spare capacity in customers per hour, but the spare fraction. Three people in the system on average, from a server that is idle a quarter of the day.

    3. Subtract the one being served — present with probability ρ — and 2.25 are left waiting.

    4. Little's law turns a population into a time and needs no distributional assumption at all: the average number in the system is the arrival rate times the average time spent in it. One hour in the system, 45 minutes of it queueing, for a job that takes 15 minutes to do.

    5. Now raise λ to 3.6. Utilisation goes from 0.75 to 0.90 — 20% more work — and ρ/(1 − ρ) goes from 3 to 9.

    Answer

    The tool prints L = 3.000, Lq = 2.250, W = 1.000, Wq = 0.750 at 75% utilisation. The lesson is the denominator of ρ/(1 − ρ): what sets the queue is not how much spare capacity you have but how much you have left as a fraction, and that fraction is what you spend when you add load. Twenty per cent more arrivals triples the queue. Another 10% on top — ρ = 0.99 — makes it 99. It is why hospitals, motorways and disk controllers fall over at high utilisation instead of degrading gently, and why "we are only at 90% of capacity" is not the reassurance it sounds like.

References (1)

Example problems

  • light load - Low utilization keeps queue and delay small.
  • heavy load - λ = 3.8 against μ = 4: the server is idle one time unit in twenty, and there are still 19.000 customers in the system on average, 18.050 of them queueing rather than being served, waiting 5.000 time units to get through. Nudge λ up by a tenth and L, Lq and W all roughly double. That is the asymptote at ρ = 1 pulling.
  • unstable - Utilization above 1 makes queue unstable.