systems theory//engineering patterns//delay as the enemy
Delay as the enemy is the engineering principle that every interval between measuring and acting costs a closed loop stability and a decision its relevance, without any warning sign until the loop oscillates; it is used to hunt delay at every stage of a system before tuning anything else, and to treat what cannot be removed as part of the model. A loop that was stable starts to ring after someone adds a smoothing filter, moves a computation to the cloud or routes a sensor through a busier bus, and nothing in the code looks wrong.
Delay as the enemy is the engineering principle that every interval between measuring and acting costs a closed loop stability and a decision its relevance, without any warning sign until the loop oscillates; it is used to hunt delay at every stage of a system before tuning anything else, and to treat what cannot be removed as part of the model. A loop that was stable starts to ring after someone adds a smoothing filter, moves a computation to the cloud or routes a sensor through a busier bus, and nothing in the code looks wrong.
The cost is easy to compute. A pure delay τ\tauτ does not change the gain of the loop but subtracts phase at the crossover frequency fcf_cfc.
Δφ=360∘ fc τ\Delta\varphi = 360^\circ\, f_c\, \tauΔφ=360∘fcτ
A rate loop crossing at 15 Hz with 4 ms of delay loses about 22 degrees of a phase margin that is usually 45 to 60; the delay margin is the delay that would eat all of it. This is why inner loops run fast with carefully designed filters, and why each loop of an autopilot runs at the rate its dynamics demand.
First remove delay, then measure what remains and put it in the model. Removing means shorter filters, faster buses, computation next to the actuator. What cannot be removed is timestamped and compensated: predict the stale measurement forward to the present (delayed measurements), or let a Smith predictor carry the dead time inside the controller.
Delay comes from places that do not look like delay. A digital filter that smooths also lags, the trade written into every low-pass; sampling itself delays by half a period on average (sampling); a sensor's internal averaging, a GPS receiver's processing, an actuator's time constant and a queue on a shared bus all add milliseconds. The catalogue of sources and their arithmetic is loop delay and, for the modelling side, delay and lag.
Distance adds delay that no tuning fixes. A loop closed through IIoT gateways or the cloud pays a round trip of tens to hundreds of milliseconds and a long tail on top, which is why the fast loop stays on the controller next to the actuator and only supervision travels.
Variation is delay too. Jitter breaks the uniform sampling every discrete controller assumes, and a real-time system is designed against the worst-case delay, since one late cycle an hour destabilizes a loop once an hour.
Uncompensated delay also corrupts estimates. A drone flying at 5 m/s with 50 ms of uncompensated latency places itself 25 cm behind where it is, the largest term in the book's error budget; unsynchronized clocks do the same (time synchronization).
Groups pay it as well. Linear consensus converges only while the communication delay stays under a bound set by the graph's largest Laplacian eigenvalue, so adding links makes a fleet faster and more fragile at once (consensus protocol).
Decision has the same enemy. A plan that arrives late is the right plan for a world that no longer exists, so an anytime algorithm keeps a valid answer from early on and is stopped when the marginal improvement falls below the cost of waiting; the OODA loop says the same of whole organizations, and MPC computation pays it as solver time. Siblings in engineering patterns.