The fast path
Wheel or pedal straight into the motion controller, out to the drives. Nothing waits on a game loop. Budget on record: 5 to 10 ms for the whole path — of which the platform's own sub-millisecond response is a small part.
Engineering · Timing
Every motion platform quotes a latency and almost none say what it was measured between. Ours is 1 millisecond, from the command being issued to the actuator beginning to move. That boundary is the important half of the sentence, because a different boundary gives a different number by two orders of magnitude.
The figure
That is the number, and that is the boundary. Position commands arrive every 1 ms, and the motor is moving before the next one lands: the interval between the platform being told where to go and the motor starting to get there is under a millisecond. It is an internal figure about the machine's own responsiveness — not a promise about what your PC, your game or your eyes will experience, which is a different measurement with a different answer.
Two budgets
This is the distinction most published latency numbers hide. The platform is quick; the chain in front of it is not always, and most of that chain is not ours.
Wheel or pedal straight into the motion controller, out to the drives. Nothing waits on a game loop. Budget on record: 5 to 10 ms for the whole path — of which the platform's own sub-millisecond response is a small part.
The game computes physics, emits telemetry at its own rate, the cue is filtered, then executed. Budget on record: 50 to 100 ms, and most of it is not ours to remove.
Quoting the sub-millisecond figure and stopping would be the easy thing to do, and it is what makes most latency claims useless. The platform figure and the path budget answer different questions and you need both.
The sub-millisecond figure is the platform's own contribution and is stated with its boundary. The two path budgets are engineering estimates from the pipeline map, published as budgets rather than as measurements.
What it is not
Under a millisecond is the platform answering a command. It is not the time from you turning a wheel to your body feeling the result, and it is certainly not the time from a game computing physics to the platform executing them.
Those journeys include the game's own output cadence, the cueing filter, the network hop and the drive loop. Add them up and the fast input path is 5 to 10 ms and the telemetry path 50 to 100 ms — most of which is not ours to remove, because a platform cannot be faster than the data it is given.
Keep reading
What the 20 kHz washout stage is actually doing to the signal, and why a platform cannot simply replay the game.
What the loop closes on, and how often — the rates this figure comes from.
The 8 kHz loop at the end of the path, and what it closes on.