How a 72 KB machine scheduled its own survival — Apollo Guidance Computer (Q138875), alarm 1201, and the birth of real-time task management
The Apollo Guidance Computer — manufactured by Raytheon (Q234276) for NASA's Apollo program — was a 2 MHz, 72 KB core-memory machine running in assembly language. Its software wasn't just guidance code. It contained a fixed-interval cyclic executive — the first production real-time scheduler in flight-critical hardware.
The AGC executive divided tasks across two timer-driven intervals:
| PARAMETER | VALUE | ROLE |
|---|---|---|
| EXECUTIVE 1 | 20 ms | Navigation, guidance, platform alignment, attitude control |
| EXECUTIVE 2 | 2 ms | High-frequency attitude correction, D-106 loop |
| PROCESSOR CLOCK | 2 MHz | ~4,000,000 cycles/second |
| MEMORY | 72 KB (core rope) | Read-only; no dynamic allocation |
| PRIVILEGES | 5 levels (0–4 + I-level) | Preemptive priority with interrupt nesting |
Executive 1 ran every 20 milliseconds. Executive 2 ran every 2 milliseconds — ten times per Exec 1 cycle. Together they formed a rigid, deterministic schedule. Not best-effort. Not cooperative. Hard deadlines, every cycle, with priority-based preemption when tasks overran.
This is the same pattern a render farm executive uses today: fixed intervals, task queues, preemptive rescheduling when a node falls behind. The hardware changed. The scheduling topology didn't.
Each Exec 1 (20 ms) cycle consisted of a table of task descriptors. For each entry, the executive checked a flag: if the task was scheduled for this cycle, it ran the code, updated the flag, and moved to the next entry. When Exec 2 (2 ms) fired, it preempted Exec 1 at the current task boundary, ran its 6 tasks, then resumed Exec 1 exactly where it left off.
The key constraint: the sum of all Exec 1 task times must be ≤ 20 ms. The sum of all Exec 2 task times must be ≤ 2 ms. If they weren't, the system couldn't keep its schedule. The designers left headroom — typically running the Exec 1 tasks in ~15-18 of the 20 available ms — so that unexpected loads wouldn't trigger preemption.
When they ran out of headroom, the system dropped the lowest-priority tasks. That's what alarm 1201 was.
During Apollo 11's powered descent on July 20, 1969, the AGC threw Alarm 1201 (and later 1202) repeatedly. The alarm codes in the AGC's Display and Keyboard (DSKY) system:
| ALARM | MEANING | ACTION |
|---|---|---|
| 1201 | Executive overflow — Exec 1 tasks exceeded 20 ms budget | Drop lowest-priority Exec 1 tasks |
| 1202 | Executive overflow — Exec 2 tasks exceeded 2 ms budget | Drop lowest-priority Exec 2 tasks |
The cause: the rendezvous radar, which should have been powered down before the descent phase, was sending continuous interrupts. Each interrupt forced the AGC to context-switch to a higher-priority I-level task that processed radar data — data the descent didn't need. These spurious interrupts ate cycles from the Exec 1 budget.
The executive responded exactly as designed: it began dropping the lowest-priority tasks in Exec 1's queue to preserve the hard deadline. It was scheduling itself out of a corner.
Gene Kranz at Capstone heard "1201, alert" and asked for the go/no-go. The answer: go. The system was shedding non-essential work to keep the critical path alive. Not a failure. A correct scheduling decision under overload.
Source: Apollo Guidance Computer (Q138875); Apollo 11 (Q43653); source code at github.com/chrislgarry/Apollo-11
Map this to the throughput model from render-farm-theory.html. The AGC executive is a single-node scheduler with:
In the Apollo 11 descent, the radar interrupts pushed T_used above 20 ms. The executive shed tasks until headroom returned to ≥ 0. The throughput equation for the landing trajectory computation remained intact because it was high-priority — it never got dropped. The dropped tasks were display refresh and non-critical calculations.
This is the exact same pattern as capacity-planner.html: when demand exceeds capacity, you shed low-priority work to preserve the critical path. The AGC just did it in 1969 with a wire-rommed executive table instead of a Kubernetes job queue.
The real-time operating system (Q213666) concept existed in theory before Apollo, but the AGC executive was the first deployed at flight scale. Compare the architectures:
| FREQUENCY | AGC EXEC 1 | MODERN RTOS (CYCLONE) |
|---|---|---|
| CYCLE | 20 ms fixed | configurable 1-100 ms |
| PRIORITY | 5 levels (hard-coded) | configurable 0-255 |
| PREENPTION | by level only | by level + FIFO within level |
| OVERLOAD | drop lowest tasks + alarm | drop lowest + configurable policy |
| MEMORY | 72 KB, no allocation | static allocation, bounded |
The principles are identical. The difference is that modern RTOSes are parameterized; the AGC was parameterized by hand in the executive tables.
Every render farm scheduler, every real-time pipeline, every task queue is a descendant of the AGC executive. The cyclic executive pattern — fixed intervals, priority-based preemption, deterministic budgeting — is the oldest and most reliable scheduling architecture in flight-critical systems. It survives because it's provably schedulable.
If you're building any system where a missed deadline matters, the AGC executive is still your reference architecture. Sixty years on, no one has improved the basic topology. They've only added more knobs.
render-farm-theory.html — throughput equations and the T=N×(F÷S)×3600 model
fault-tree-analysis.html — failure decomposition with SVG gate diagrams
render-farm-calculator.html — interactive capacity calculator
cluster-scaling.html — linear scaling law proof
agc-executive.json — machine-readable task table and timing parameters