Determinism at 60 Hz, animated

Back to Research Lab

Hard Real Time · Safety-Critical Systems

⏱ A Level D simulator is legally a substitute for the aircraft (an airline logs real type-rating hours on it), so its fidelity requirements are written as regulation rather than as goals. The strictest is transport delay: 150 milliseconds from a pilot's control input to the motion, visual and instrument response. This animation works out what that ceiling costs in engineering terms: why a healthy-looking mean frame time is the wrong statistic, how latency composes as a maximum across a rack of hosts while reliability composes as a product, and why the telemetry that proves it has to ship as part of the product.

Engineering Reference: Transport-delay and qualification limits are public: FAA 14 CFR Part 60 and the equivalent EASA CS-FSTD(A). The engineering discipline is drawn from the author's work on Level D full-flight-simulator systems at Avion, including the live monitoring layer described in the ACE architecture report. No employer design is disclosed; the topology shown is the generic multi-host layout common to every Level D device.
🧠 What did you just learn?

150 ms is a gate, not a target. Transport delay is the total system processing time from a pilot primary-flight-control input until the motion, visual or instrument systems respond. FAA Part 60 and EASA CS-FSTD(A) cap it at 150 ms for Level C/D aeroplane devices, and at 100 ms for helicopters, because a hovering rotorcraft is unstable and the pilot closes the loop far faster. Miss the ceiling and the device does not qualify; the hours flown on it do not count.

A deadline is never met on average. At 60 Hz each frame gets 16.67 ms. A mean of 8.6 ms looks like a system with half its budget spare, but the mean is the wrong statistic: what matters is the tail mass past the deadline. A four-hour session is 864,000 frames, so E[K] = N·p: one bad frame in a hundred thousand still costs ~9 overruns a session, and a 99.9% success rate costs 864 of them.

And that estimate is the optimistic one. E[K] = N·p assumes frames fail independently. They don't: a garbage-collection pause, a page fault or a network stall takes out a run of consecutive frames, so real sessions cluster their failures into visible stutters rather than spreading them thinly.

Distributed systems compose badly, in two directions at once. A full-flight simulator is a rack: flight model, avionics, three visual channels, sound, motion, instructor station. The frame closes when the last host publishes, so latency composes as a maximum: one straggler at 19 ms makes the frame late for everyone. Reliability composes as a product: nine hosts at three nines each give 0.999⁹ ≈ 99.1% clean frames, about 7,800 bad frames per session. This is why the budget must be allocated and enforced per host: a system-wide average is not something anyone can engineer against.

Ship the instrument with the system. Sampled step time can miss a spike that happens between two polls; an overrun counter is incremented by the runtime at the moment the deadline breaks and cannot be missed. Monotonic counters are the trustworthy primitive for deadline compliance; sampled gauges are for trend. Determinism is not optimised in at the end: it is a budget, allocated per host, enforced every frame, and proven by telemetry that is part of the deliverable.

📐 The math, precisely

Rendered on load. If equations appear as raw text, your browser blocked the math font CDN.