PID

What PID is, and what it isn't

The shape is simple enough to fit on a napkin. Measure error — the gap between where the system is and where you want it. Multiply that error by a constant (P). Add the running sum of past errors, scaled by another constant (I). Add the current rate-of-change of the error, scaled by a third (D). Sum the three. That is your control output. Repeat every tick.

P gives you responsiveness — a stiff spring that pulls toward the setpoint. Crank it up and the system gets fast and twitchy; eventually it overshoots and rings. I closes the steady-state gap — without it, a P-only loop will sit near the target but rarely on it, because the spring force at zero error is zero. D is the damper — it reads the slope of the error and pulls against it, so the system stops before it overshoots rather than after. Three knobs. One feedback loop. Sixty years of process plants run on this.

The reason it shows up everywhere isn't that it's optimal — it usually isn't. It's that it works without a model. You don't need to know the dynamics of the plant. You tune three numbers against a real system until it stops oscillating. For most slow, roughly-linear processes — a temperature bath, a cruise-control loop, a glucose pump titrating insulin against interstitial CGM readings — that is enough. Modern artificial-pancreas trials still benchmark against PID, though Model Predictive Control now beats it on time-in-range when a decent metabolic model is available.

What I find interesting is how rarely software actually reaches for PID, even when the textbook says we should. Kubernetes' HPA looks like a candidate — error between current and target CPU utilization, a pod count to adjust — and yet the algorithm is a rolling-window maximum, not a PID loop. TCP congestion control is a textbook feedback problem and the answer was AIMD: linear-up, multiplicative-down, no derivative term, no integral term, no proportional gain in any classical sense. iOS scroll deceleration is, on inspection, an overdamped exponential decay — a critically tuned spring, not a controller. Linux's schedutil is a direct utilization-to-frequency map. Each of these is a feedback system. None of them is PID.

The pattern, once I noticed it: software builds simpler controllers than control theory says it should, because software systems break the assumptions PID quietly leans on. PID assumes a roughly linear plant, a stationary setpoint, a well-behaved sensor, and that integrating past error is meaningful. None of those hold for a queue under bursty load. Integral windup — the integrator silently accumulating error during a saturation period and then overcorrecting — is brutal in a system where the actuator is "start more pods" and the cost of overcorrection is a bill. Derivative kick from a noisy metric — CPU utilization sampled every 15 seconds — is worse than no derivative term at all. The honest move is to drop the gains you can't tune and keep only the ones you can defend. AIMD is what's left of PID after you concede that you don't know the plant and you'd rather under-react than ring.

So the lesson I'd draw, against the version of me that wanted PID to be a master key: PID is a beautiful default for systems someone has bothered to model. For everything else — most production software — the right controller is usually simpler, more conservative, and asymmetric. Linear up, multiplicative down. A rolling max instead of an integral. A spring with no derivative. Worth knowing PID for the vocabulary it gives you. Worth knowing why we keep not using it.

Refs: Åström & Murray, Feedback Systems (CDS Caltech, ch. 10 PID); HPA stabilization design (kubernetes/enhancements KEP-853); AIMD on Wikipedia & Peterson/Davie §6.3; UIScrollView deceleration analysis (Lobanov, 2018); artificial-pancreas PID vs MPC trials (Endocrine Reviews, 2019).