Feedback delay beyond the loop cycle causes overshoot and oscillation

What it is

Closed-loop correction depends on feedback promptly reflecting the true current state. If feedback itself takes longer than the normal loop cycle to arrive, what the user actually receives is state information that's already stale — the correction made from it targets a state from tens or even a hundred-plus milliseconds ago, not the present. This produces correction that's consistently "a step late and too forceful": it first flies past the target (overshoot), then, working from equally stale feedback, applies another excessive correction in the opposite direction — back and forth, producing oscillation rather than settling smoothly onto the target.

Why it happens

Under normal conditions, closed-loop control assumes "the state I'm seeing now" is roughly equal to "the state the movement is actually in," and correction commands are generated against the present gap. Once feedback delay exceeds the loop's own cycle time, the state the user sees is already behind where the movement actually is, so the magnitude and direction of the correction computed from it are sized to the gap as it stood in the past, while what's actually being corrected is the present gap — the two frequently don't match. If the movement has already started returning as a result of an earlier correction while feedback hasn't caught up yet, the user mistakenly believes more correction is still needed, and ends up overcorrecting. That overcorrection then has to pass through the same delay before it's perceived, so the next round of correction is again aimed at a state that's already stale — the error doesn't converge but instead swings back and forth across the target, and the larger the delay and the stronger each correction, the larger that swing gets.

Studying it

A common way to study this artificially adds a controllable delay to the feedback channel (updating cursor position a fixed number of milliseconds after the hand actually moves, for instance), systematically varies that delay, and observes the delay threshold at which the trajectory shifts from smooth convergence into a clear overshoot-and-reverse-correction pattern; this threshold typically lines up with the loop cycle time measured for that task, confirming the mechanism that delay beyond the loop cycle triggers oscillation. Another approach draws directly on real task data from teleoperation or high-latency network settings, comparing delay magnitude against trajectory oscillation amplitude and completion time.

Where it stops holding

Whether oscillation occurs depends not just on the delay itself but also on the magnitude of each correction — if a user or system responds to the error signal conservatively (making only small corrections each time), even a fairly long delay is unlikely to produce violent overshoot; conversely, if the response magnitude is large, even a moderate delay is enough to trigger clear oscillation. This means delay alone isn't enough to predict whether trouble will occur — it has to be assessed together with correction magnitude or gain, and this tradeoff's boundary can differ quite a bit across input devices (mouse, touchscreen, freehand gesture).

Applying it

• Any interaction that requires the user to perform continuous closed-loop correction based on visual feedback (a remote-controlled cursor, freehand gesture aiming, a cloud-rendered drag preview) should keep the delay between an action being issued and its feedback being displayed under the loop cycle time measured for that task; beyond that magnitude, expect overshoot and back-and-forth correction, not user unfamiliarity with the operation.
• Where delay itself can't be eliminated entirely (network transmission, progressive rendering), consider lowering the system's response magnitude to a single correction, or adding visual damping cues (giving cursor movement a slight easing lag rather than tracking the hand exactly) — trading a lower gain for less oscillation instead of chasing zero latency at all costs.
• How to check: in a controlled test setting, gradually increase feedback delay and log the number and magnitude of direction reversals in the trajectory. Once the number of reversals rises noticeably and their magnitude stops shrinking over time, the delay has crossed that task's loop-cycle threshold, and it needs to be addressed from both the delay itself and the response gain.

Related

• Same group: A8.07.1 Closed loop relies on continuous feedback to close in on the target step by step · A8.07.2 Each correction needs at least one full feedback-loop cycle · A8.07.4 Final landing accuracy is set by the closed-loop phase · A8.07.5 Closed loop degrades to open loop when the feedback channel is lost
• Nearby: A8.01 The Composition of Reaction Time · A1.14 Motion Perception
• Search terms: feedback delay · control oscillation · overshoot correction