Input lag is not one setting. The delay a player feels can accumulate in the controller or mouse, connection, operating system, game simulation, CPU scheduling, render queue, GPU work, frame presentation, display processing, and sometimes the network. A change log makes tests comparable and prevents a random settings spree from being mistaken for diagnosis.
Define the symptom and the measured boundary
Record game and build, platform, mode, map or scene, device and connection, display model and mode, resolution, refresh rate, frame cap, synchronization settings, graphics preset, driver, operating system, background apps, power mode, and network conditions. State whether the symptom is local input-to-display delay, online command response, stutter, frame pacing, or controller disconnection.
Microsoft's Dynamic Latency Input documentation defines gaming input lag as the delay between physical input and output and distinguishes controller reports, game input reads, and platform synchronization. Keep network latency separate from local system latency unless the test deliberately measures both.
Establish a repeatable baseline
Choose a repeatable training area, replay, benchmark, or camera movement. Warm the system, close unrelated workloads, and record multiple runs rather than one best result. Capture average and percentile frame time, frame-rate stability, CPU and GPU utilization, clock behavior, display refresh, and any supported latency metric. Keep the same scene and input action.
Microsoft's Windows input-latency guidance explains that event queues, rendering cadence, display refresh, and presentation queues all affect response. Higher FPS can help, but frame rate alone does not identify where delay occurs.
Build the change timeline
List game patches, driver and operating-system updates, controller firmware, cable or wireless changes, display input and firmware, new overlays, capture tools, graphics presets, frame caps, VSync or variable-refresh changes, power settings, background applications, and network configuration. Identify the last known-good and first known-bad session.
Record automatic changes too. A game may rebuild shaders, reset display mode, change resolution scale, or enable frame generation after an update. A television may switch out of game mode for a new HDMI input.
Isolate the latency chain
Compare wired with wireless input, a second known-good device, one USB port, local with online mode, one display input, game mode on and off, stable low and high graphics loads, and overlays disabled. Change one variable per run. Do not update driver, switch display mode, change frame cap, and lower graphics simultaneously.
NVIDIA's Reflex overview distinguishes FPS from system latency and describes game, render, PC, mouse, and display measurement paths. Some measurements require supported games, GPUs, displays, or peripherals; mark unavailable metrics as unknown instead of estimating them.
Apply a reversible hypothesis test
Write each candidate cause with evidence, test, expected result, and rollback. Examples include an unstable wireless link, saturated GPU, excess render queue, duplicate frame cap, display processing mode, background capture, thermal throttling, or a patch regression. Use supported settings and avoid unsafe overclocking as a first diagnostic step.
If one change improves the median but worsens stutter or image tearing, record the tradeoff. Responsiveness, visual consistency, power, temperature, accessibility, and stability are all part of the decision.
Verify across conditions
Repeat the baseline after the repair, then test a demanding scene, low-load scene, long session, pause and resume, controller reconnect, and online play if relevant. Confirm that display refresh and frame pacing remain stable and that the change survives restart. Test affected and unaffected games to distinguish a title-specific regression from a system-wide problem.
Close the log with confirmed cause only when repeatable evidence supports it. Record old and new values, measurement method, run count, uncertainty, rollback, and any unsupported hardware boundary. The repair is credible when another person can reproduce the baseline, apply one documented change, observe the same improvement, and restore the original configuration without guessing.
Sources
- Dynamic Latency Input — Microsoft Learn
- Optimize input latency for UWP DirectX games — Microsoft Learn
- NVIDIA Reflex Low Latency Platform — NVIDIA