Skip to content
Accelerometer test rig mounted to the DDX Precision motion platform

Where does the timer start? Simulator latency, measured

Latency is perhaps the single most important factor in whether a simulated vehicle controls like its real-world counterpart. A car at the limit is balanced on the edge of stability, acutely sensitive to every input, and added lag pushes corrective inputs toward overcorrection, oscillation, and loss of control. Yet latency is often marketed as a single "too good to be true" number (0 ms? 1 ms?) with no explanation of what was measured: input-to-motion, telemetry-to-motion, command-to-motion, servo response, or just the loop period of a sub-component?

Where the timer starts, and where it stops

We instrumented every stage of the DDX Precision pipeline. Oscilloscope probes on the button contact and the USB data pins of a Cube Controls GT v2 wheel rim. An LED wired to the same contacts and a 960 Hz camera on the display. A high-speed analog accelerometer on the platform, on the same oscilloscope as the button probe. Time is measured from button press to accelerometer onset - the simulation's physics, its telemetry, our software, our controller, and the servos all included.

On a tested USB wheel-rim input, physical button-contact to outbound polled USB status-packet latency measured 0.4-4.3 ms across 21 trials, averaging 2.7 ms with a 2.9 ms median.

Across five tested racing simulations on DDX Precision, median physical-input-to-platform-motion onset ranged from 7.0 to 24.5 ms across 95 trials. Per-title medians were 7.0 ms in Assetto Corsa, 8.0 ms in AC EVO, 11.0 ms in Le Mans Ultimate, 13.0 ms in Automobilista 2, and 24.5 ms in iRacing.

Every sample sits above a 6.4 ms floor - the input device's 2.9 ms median plus the DDX stack's 3.5 ms. Nothing below that line is available to any motion system on this input path, and the spread above it belongs to the simulation. In Assetto Corsa, the platform was already moving after a median 7 ms - before the display produced its first changed pixel (measured at an average 11 ms).

The part that is ours

On production DDX Precision hardware, the DDX-controlled path from raw simulation telemetry to the first detected platform acceleration totals approximately 3.45 ms: approximately 0.3 ms for Dynamo filtering and cue construction, approximately 0.75 ms for PC-to-controller communication, and 2.4 ms to motion onset. DDX Precision and DDX Prime operate within an approximately 2.5-3.5 ms telemetry-to-motion latency envelope, measured from raw simulation telemetry arriving at Dynamo to accelerometer-detected physical motion onset.

This performance comes from the complete control stack, not a single fast component or a datasheet specification. DDX Dynamo converts irregular simulation telemetry into a clean 1 kHz stream, constructs motion cues with minimal filtering delay, and delivers commands at high cadence to our real-time motion controller. That reliable command stream allows us to run industrial-grade servos with tight, aggressive tuning. Many consumer systems must mask lower or irregular command rates with additional smoothing and relaxed servo loops. The result may look smooth, but it starts late, follows loosely, and suppresses the subtle and high-frequency information the driver needs.

Three questions for any latency number

In anonymized DDX reference evidence, observed physical-input-to-platform-motion onset was approximately 40 ms, 80-120 ms, and 200 ms across three selected non-DDX motion systems. Separately, another system used a 40 Hz command cadence—25 ms between commands before downstream filtering or actuation—and one professional vendor published a figure greater than 30 ms without a sufficiently defined boundary. These are heterogeneous market reference points, not a controlled head-to-head ranking. They are far more believable than a single-digit marketing figure: USB input, simulation, filtering, motion cueing, and electromechanical response time add up quickly if not controlled.

A software loop period, transmission time, servo specification, or response to an idealized step is not physical-input-to-platform latency. When evaluating any latency claim, ask three questions: Where does the timer start? Where does it stop? How was physical motion detected? If those answers are missing, the number is marketing - not performance data.

The long pole is the simulation

The DDX stack is already fast enough that the simulation itself becomes the long pole. Measured at the median in iRacing: input, physics, and telemetry take about 21 ms, and the DDX software, hardware, electrical, and mechanical stack adds roughly 3.5 ms on top of that, for a total of 24.5 ms from physical input to motion onset. Conventional interpolation smoothing would add approximately 17 ms more - 42 ms in total. DDX PreActiv attacks that remaining delay by predicting vehicle state across the telemetry cadence gap, instead of waiting for the next simulation frame. It turns simulation latency from an external limitation into another problem our software can solve.


Read the full report. Simulator Latency publishes every stage measurement - input device, display, motion, command response, and the Dynamo software path - with the protocol and the boundary for each.

Download the white paper (PDF)

The stack this report measures is described in the first paper of the series: Software-Defined Motion.

Or feel it for yourself: book a demo in Bellevue, WA or Austin, TX.

Study note: USB latency is one tested device and does not generalize to all input hardware. Input-to-motion is button contact to first accelerometer-detected platform acceleration on one DDX Precision configuration; title-dependent excitation and cadence make this an observed range, not a controlled ranking of game engines. The telemetry-to-motion envelope is motion-subsystem latency, not physical-input-to-motion or whole-simulator latency. The 42 ms figure describes a conventional interpolated pipeline, not DDX's measured performance. Non-DDX motion systems remain anonymized; that evidence is heterogeneous and not a controlled comparison.