One line changes. Below s customers an arrival finds a free server, so adding a customer adds a busy server and the service rate rises with n; at and above s every server is busy and the rate stops rising. That is μₙ = min(n, s)μ, and the cut equations do not notice, because they were never told the rates were constant. Erlang C is not a second formula on this page: the probability an arrival has to wait is the probability the system is already at s or above, which is πₛ + πₛ₊₁ + ⋯, added up from the distribution the cuts produced. The closed form from the System Design core sits beside it.
Core ideas
Three ideas. The first is the model, the second is what Erlang C actually is, and the third is a sentence that is true only under a condition and used to be printed without it.
With n customers and s servers, min(n, s) of them are busy, so the completion rate out of state n is min(n, s)μ. Below s the chain speeds up as it fills; at and above s it cannot speed up any further. Nothing else about the model changes, and the cut equations apply unaltered because they never assumed a constant rate.
An arriving customer waits exactly when every server is already busy, that is when the system is at state s or above. So the waiting probability is Σ_{n ≥ s} πₙ, summed from the distribution the cuts produced. The closed form erlangC from sysdesign_core is printed beside it as a check on the truncated chain, and at three servers on the worked load both give 44.444%.
The offered load a = λ/μ is a property of the arrivals and the service, and neither moves when a server is added: the same work arrives and, while the queue settles, the same work is done. What collapses is the probability of waiting — from 96.296% at two servers to 44.444% at three to 17.391% at four, at a fixed load of 2. That is the argument for pooling as a number.
The material
The rate list, the waiting probability read off π, the pooling table, and the one sentence that needed a condition attached to it.
A birth-death chain with λₙ = λ for every n and μₙ = min(n, s)·μ, where μ is the rate of ONE server. Write a = λ/μ for the offered load and ρ = a/s for the utilisation per server.
An arriving customer waits when all s servers are busy, which is exactly when the system is in state s or above. That probability is Erlang C.
Two ratios and it is easy to use the wrong one. a = λ/μ is how much work arrives per unit time, measured in server-loads; it is 2 on the worked example whether there are two servers or five. ρ = a/s is the fraction of each server's time that work would occupy, and it is the one that has to be below 1 for an unbounded queue to settle.
The two figures are computed from different things. The left one is a sum of entries of the truncated chain's π; the right one is the closed form for an unbounded M/M/s, 4/9 exactly. They agree to well under a millionth here, and the page prints a green tick when they do. On a chain kept too short for its load they will not, and the page will say so — which is the correct behaviour, because the disagreement is real and belongs to the truncation.
The third row is where the system becomes usable and the second is where it is not. At two servers ρ = 1 exactly: the work arriving equals the work the servers can do, the unbounded queue does not settle, and the only reason a finite Lq appears at all is the truncation at forty states. At three the utilisation is two thirds and the waiting probability has fallen by more than half. Nothing about the arrivals or the service changed between those rows.
Notice also the last column. Each server is busy 66.67% of the time at three servers and 40% at five, so the per-server utilisation falls as the waiting falls — which is the price of pooling and the reason it is a trade rather than a free lunch. “Many Servers: Pooling, and Erlang C” makes the same comparison from the closed forms; this page makes it from a distribution you can see.
The expected number of busy servers is Σ min(n, s)πₙ, and on a queue that settles it equals the offered load a: every arriving customer is eventually served, so the work completed per unit time equals the work arriving, and adding a server does not change either. At a = 2 the busy count is 2.0000 at three servers, at four and at five.
Set λ = 2, μ = 1 and one server. The offered load is still 2. The expected number of busy servers is 1.0 — it cannot exceed s = 1 — and the work the server finishes is 1 per unit time against the 2 arriving.
So “on average a's worth of work is being done, whatever s is” is false here, and this page used to print it without a condition. The banner now branches on ρ: below 1 it states the identity, and at ρ ≥ 1 it says instead that the servers cannot keep up, prints what they do finish, and notes that only the truncation stops the difference piling up without bound.
That correction is worth dwelling on, because the false version is more memorable than the true one and survives being half-remembered. The identity “throughput equals offered load” is a conservation statement about a system in equilibrium, and a system at ρ ≥ 1 has none; what it has is a backlog growing at λ − sμ per unit time, which “Transient Overload and Draining the Backlog” is about.
With λ = 3, μ = 2 and two servers the offered load is 3/2 and ρ = 3/4. The chain gives P(wait) = 64.285% and Lq = 1.928, and the closed form gives 64.286%.
The two differ by about three parts in a million, which is larger than the page's own agreement threshold, so it prints a disagreement here even though nothing is wrong: the chain is kept to forty states at a load whose tail decays like (3/4)ⁿ. The lesson is the one the preceding material made — a truncated chain is a different model — and the threshold is a property of this page rather than of the mathematics.
Interactive
one change to the rate list, and Erlang C read off the distribution it produces
Method
Four steps. The first two are about which ratio you are holding, and the fourth is the one that turns a table into a decision.
a = λ/μ in server-loads, ρ = a/s per server. a is a property of the demand and the service; ρ is what you change by adding capacity. Writing both down stops the standard slip of comparing a load of 2 against a utilisation of 2.
No new model and no new formula. The cut equations give the ratios, the product gives the weights, normalising gives π, exactly as on a single server.
P(wait) = Σ_{n ≥ s} πₙ. This is what Erlang C is. Having it as a sum rather than as a formula is what lets you answer a variant — a finite waiting room, a customer who balks — where the formula does not apply.
Hold the load and vary the servers: the waiting probability falls sharply and the per-server utilisation falls with it. Both columns are the decision. A table that shows only the waiting makes pooling look free.
Arrivals at 2 per unit time, each server completing 1 per unit time. The offered load is 2 in every row below; only the number of servers changes.
The Lq column is the one that makes the case. Going from two servers to three takes the expected queue from about eighteen to under one — a factor of twenty for one more server, at a load that did not change. That is not a smooth trade-off; it is the collapse that happens as ρ comes away from 1, and “The Knee: Response Time vs Utilisation” is the same phenomenon seen from the other side.
The two-server row deserves suspicion rather than admiration. ρ = 1 exactly, so the unbounded queue does not settle at all and Lq = 18.3 is a fact about keeping forty states. Drag the state count up and it grows; the closed form refuses the row entirely. A finite number appearing where none should is exactly the failure mode the preceding material warned about.
The last line is the honesty fix. At one server the offered load is 2 and the busy count is 1, so the tidy sentence “busy servers equals the offered load whatever s is” is false. It is true while the queue settles, and the page now branches on ρ and says the other thing when it does not.
For a rehearsal, keep three servers and raise λ from 2 to 3. The supplied first move is that a becomes 3 and ρ becomes 1. Predict what happens to P(wait) and to the agreement with the closed form, then check: one of the two columns stops existing, and the other keeps printing a number.
You should be able to write μₙ = min(n, s)μ, keep the offered load and the utilisation apart, read the waiting probability off π as P(N ≥ s), produce the pooling table at a fixed load and read both of its consequences, and state the condition under which busy servers equals offered load together with a case where it fails.
Something to change about this lesson? Write it down, tick it off when it is handled, and export the list when you want to act on it. Kept in this browser only: nothing is sent anywhere, and nobody is notified.
No recommendations yet for this lesson.