⏱️ Lectura: 13 min
The elevator algorithm problem is more than 60 years old: the first formal solution, SCAN, was patented in 1961 and still underlies much of the systems running today in buildings around the world. An interactive article published on john.fun breaks down step by step how these elevator algorithms work, from the simplest to Otis’s proprietary RSR system, and leaves an uncomfortable finding: kiosks that ask for your destination floor before you board tend to give worse wait times than traditional buttons.
📑 En este artículo
For any developer who has dealt with load balancing, job queues, or process schedulers, this is the same problem in a different disguise: several workers (the cabins), a queue of requests arriving in uneven bursts, and a success metric that isn’t the average but the tail of the distribution.
TL;DR
- The SCAN algorithm was patented in 1961 and still underlies many elevator systems.
- LOOK, the most widely used variant today, avoids going all the way to the top floor if nobody requested it.
- Otis’s RSR (Relative System Response) algorithm scores each cabin and reassigns passengers every 5 seconds.
- The key metric isn’t the average: it’s the p90, the wait time for 90% of passengers.
- Under high traffic flow, LOOK ends up outperforming RSR because the cabins are always full.
- Destination kiosks tend to give worse wait times than simple buttons, except in buildings with 8 or more cabins per core.
- The peak congestion time is the morning, when almost all traffic goes from the lobby to the upper floors.
- RSR penalizes cabin bunching in the same direction and rewards cabins that are idle within two floors of the call.
What Happened
The john.fun article isn’t an academic paper or a product announcement: it’s an interactive simulation that lets you move traffic sliders and see, in real time, how wait times change depending on the chosen algorithm. It compares four approaches: SCAN, LOOK, RSR (Otis’s proprietary algorithm), and destination dispatch, the kiosk system that replaces up/down buttons with a keypad asking for the destination floor.
The piece uses two concrete metrics to compare these elevator algorithms: the percentage of trips with a wait under 30 seconds and the percentage with a wait under 90 seconds. Those two figures are enough to show something intuition doesn’t anticipate: the more sophisticated system (RSR) doesn’t always win, and neither does the destination kiosk, which on paper has more information.
Context and History
The elevator algorithm problem is old. The first formal solution, SCAN, was patented in 1961. The idea is simple: the cabin starts at the lobby, goes up to the top floor picking up and dropping off people along the way, and only then reverses direction and goes down. It’s easy to implement and predictable, but has an obvious flaw: it’s almost never necessary to reach the top floor.
The fix for that flaw is called the LOOK algorithm: the cabin only goes up to the highest floor someone requested, not to the top of the building, and reverses there. It’s the behavior most people take for granted when they think about how an elevator works. For decades, LOOK (or close variants) was the de facto standard in buildings with a single cabin.
The problem gets more interesting with multiple cabins. The most basic solution is a central scheduler that assigns each call to the nearest cabin. It works, but leaves room for improvement: it doesn’t account for whether that cabin is already full, whether another cabin will pass the same floor in the same direction, or whether it’s worth keeping an idle cabin near the call for the next request.
Technical Details and Performance of Elevator Algorithms
This is where Otis’s RSR algorithm comes in. RSR (Relative System Response) assigns a score to each candidate cabin for handling a call, and picks the one with the lowest score. The formula, as the article describes it, combines several factors:
Score = ETA_to_pickup
+ current_load_penalty
+ anti_bunching_penalty
- direction_match_bonus
- nearby_idle_cabin_bonus
- low_load_bonusTwo design details are worth highlighting. First, the anti-bunching penalty: if another cabin is already headed to the same floor in the same direction, RSR penalizes the second cabin to prevent two elevators from arriving together and leaving the rest of the building without service for a while. Second, the nearby idle cabin bonus: a cabin parked within two floors of the call earns points in its favor, so there’s always reserve capacity near active zones.
The other key element is that RSR doesn’t assign once and stop there: it recalculates every 5 seconds. If cabin A, which was going to pick up a passenger, falls behind due to other stops, the system can reassign that call to cabin B in real time. That constant re-optimization is, according to the article, the piece that most improves traffic flow compared to a fixed assignment made at the moment of the call.
The correct way to measure how good an algorithm is isn’t the average wait time. An average hides the people who wait a long time while most people wait very little. The metric that matters is the full distribution: the p50 (median) and especially the p90. A p90 of 2 minutes means 90% of passengers waited 2 minutes or less, but also that 1 in 10 waited longer. That long tail is what people remember when they say the elevator takes forever.
Traffic isn’t constant throughout the day either. In a typical corporate building, mornings are dominated by trips from the lobby to the upper floors; afternoons reverse the pattern; midday mixes both directions; and the rest of the day is mostly floor-to-floor traffic. The time slot with the worst wait statistics is consistently the morning: everyone enters at the same time and in the same direction, so there’s no room to combine trips.
| Algorithm | When It’s Best | Advantage | Limitation |
|---|---|---|---|
| SCAN | Simple single-cabin systems | Predictable, easy to implement | Goes to the top floor even if nobody requested it |
| LOOK | Default standard in most buildings | Doesn’t waste trips to the top of the building | Doesn’t coordinate well with other cabins in large buildings |
| RSR | Buildings with multiple cabins and moderate traffic | Reassigns every 5 seconds and avoids bunching | Loses its edge when flow is so high that all cabins are full anyway |
| Destination Dispatch | Very tall towers with 8 or more cabins per core | Knows each passenger’s destination before assigning | Gives worse wait times than simple buttons in most buildings |
The crossover between LOOK and RSR is one of the most counterintuitive findings of the analysis. As call volume rises, LOOK starts to outperform RSR. The explanation is mechanical: when cabins are always full and stop at nearly every floor anyway, RSR’s extra rules (anti-bunching, idle cabin bonus) stop having room to make a difference. The same thing happens in small buildings with few cabins per core: there are so few options to choose from that the sophistication of the scoring doesn’t change the outcome.
💭 Key point: destination dispatch has all the information (it knows which floor you’re going to before you board), but in most buildings it gives worse wait times than a simple up or down button. It only wins in very tall towers with 8 or more cabins per core.
The reason, as the article describes it, has to do with the rigidity of the assignment: once the kiosk assigns you a specific cabin, you’re locked into it even if another cabin passes your floor sooner. Traditional buttons, on the other hand, let any available cabin respond to the call, giving the optimizer more flexibility when deciding.
flowchart TD
A["New call on a floor"] --> B["Calculate ETA for each cabin"]
B --> C["Add load and bunching penalty"]
C --> D["Subtract direction and nearby idle bonus"]
D --> E["Choose cabin with lowest score"]
E --> F["Reevaluate everything every 5 seconds"]
F --> BHow to Try It
You don’t need to install anything to see the algorithms in action: the interactive simulator at john.fun/elevators runs in the browser and lets you adjust the arrival flow and compare live the percentage of waits under 30 and 90 seconds between LOOK and RSR.
If you want to dig into the code, a simplified simulation of the LOOK algorithm fits in a few lines of JavaScript. This example moves a single cabin between floors and handles calls in the order the route crosses them:
function simularLook(pisos, llamados) {
let piso = 0;
let direccion = 1;
const log = [];
while (llamados.length > 0) {
const enEstePiso = llamados.filter(l => l.piso === piso);
enEstePiso.forEach(l => log.push({ piso, evento: "recogida" }));
llamados = llamados.filter(l => l.piso !== piso);
const quedanArriba = llamados.some(l => l.piso > piso);
const quedanAbajo = llamados.some(l => l.piso < piso);
if (direccion === 1 && !quedanArriba) direccion = -1;
if (direccion === -1 && !quedanAbajo) direccion = 1;
piso += direccion;
piso = Math.max(0, Math.min(pisos - 1, piso));
}
return log;
}To measure the p50 and p90 of that simulation (the metric that actually matters, as we saw above), you just need to save the wait time of each call and sort them:
function percentil(tiempos, p) {
const ordenados = [...tiempos].sort((a, b) => a - b);
const idx = Math.floor((p / 100) * (ordenados.length - 1));
return ordenados[idx];
}
// tiempos = [12, 45, 8, 90, 23] wait time in seconds per call
console.log("p50:", percentil(tiempos, 50));
console.log("p90:", percentil(tiempos, 90));Running that same simulation with different call arrival rates is the most direct way to reproduce, on a small scale, the crossover between LOOK and RSR shown in the original article.
💡 Tip: if you’re going to compare algorithms in your own simulation, run each configuration with thousands of random calls before comparing the p90: with few samples, the tail of the distribution varies too much to draw conclusions.
Impact and Analysis
This problem’s appeal to a developer isn’t just curiosity. It’s the same pattern that shows up in a load balancer distributing requests across replicas, a scheduler deciding which node to place a process on, or a job queue distributing jobs among workers. In all four cases there are limited resources (cabins, replicas, nodes, workers), demand arriving in uneven bursts, and the temptation to add increasingly sophisticated rules to optimize better.
What the RSR-LOOK crossover shows is a lesson that repeats in distributed systems: adding scoring rules doesn’t always improve the outcome, and under high load conditions, a simple, predictable algorithm can perform as well as or better than a sophisticated one. The same pattern seen in elevator algorithms appears, for example, when a load balancer uses round robin instead of least-connections rules under certain traffic levels.
The destination dispatch case also has a direct parallel: it’s tempting to think that more input information (knowing the exact destination before assigning) always improves the allocation. The article’s finding says the opposite in most cases: the rigidity of tying a passenger to a specific cabin from the start takes away the optimizer’s room to maneuver. In queuing systems, the equivalent would be fixing in advance which worker will process each task instead of letting whichever one frees up first take it.
What’s Next
The john.fun article doesn’t mention plans to expand the simulator, but it leaves open a question the text itself acknowledges as out of scope: how these algorithms compare in in-cabin travel time, not just wait time before boarding. RSR and LOOK behave differently there too, according to the author, though without going into detail.
For anyone who wants to keep exploring, simulating elevators is a classic computer science exercise: SCAN and LOOK are taught in operating systems courses as disk scheduling algorithms (not just elevator algorithms), and in operations research courses they appear as a case study of multi-server queues.
📖 Summary on Telegram: View summary
Try it yourself: open the simulator at john.fun/elevators, increase the call flow per minute, and watch live as LOOK starts to beat RSR.
Frequently Asked Questions
What’s the difference between SCAN and LOOK?
SCAN always travels to the top floor of the building before reversing direction, even if nobody requested that floor. LOOK fixes that: the cabin only goes up or down to the highest or lowest floor someone requested, and reverses there. LOOK is the variant most buildings use today.
What is Otis’s RSR algorithm?
RSR (Relative System Response) is a proprietary Otis algorithm that assigns a score to each available cabin for handling a call, combining estimated arrival time, current load, penalties for bunching with other cabins, and bonuses for proximity or idleness. It always picks the cabin with the lowest score and recalculates everything every 5 seconds.
Why aren’t destination kiosks always better?
Because they tie the passenger to a specific cabin from the moment they enter their destination floor, even if another cabin ends up better positioned afterward. Traditional buttons let any available cabin respond, which gives the assignment system more flexibility.
What does it mean if the p90 wait time is 2 minutes?
It means 90% of passengers waited 2 minutes or less for the elevator, and the remaining 10% waited longer. It’s a more honest metric than the average because it shows the long tail of uncomfortable waits that people actually remember.
Why does the morning have the worst waits?
Because almost all the traffic goes in the same direction, from the lobby to the upper floors, so there are no mixed trips an algorithm can combine to save stops. In the afternoon the pattern reverses, and at midday it mixes with floor-to-floor traffic.
Which buildings benefit from destination dispatch?
The article points out that it wins, though as an exception, in very tall buildings with 8 or more cabins per core. Outside that case, simple up and down buttons tend to give better wait times.
References
- john.fun/elevators: the original interactive article with simulators for SCAN, LOOK, RSR, and destination dispatch.
- Wikipedia: Elevator algorithm: general overview of the SCAN algorithm and its variants.
- Wikipedia: Destination dispatch: background on destination kiosk systems.
- Otis Elevator Company: the manufacturer that developed the RSR (Relative System Response) algorithm mentioned in the article.
📱 Enjoying this content? Follow @programacion on Telegram for daily tech content in Spanish: quick summaries, fresh content every day.
Imagen destacada: Foto de Julia Taubitz en Unsplash
0 Comments