Document input lag by defining exactly which delay is being measured, the complete test environment, every setting that can affect the path, the reason for each choice, and the owner of the next action. Record the game and build, workload, input device and connection, display, refresh rate, presentation mode, frame cap, VSync, variable refresh, graphics settings, driver, operating system, measurement tool, raw results, and acceptance threshold.
Define the latency boundary
State whether a number represents peripheral delay, game processing, render submission, graphics queue, display presentation, or an end-to-end input-to-photon path. Do not compare results whose boundaries differ. NVIDIA's PC latency overview separates peripheral, game, render, PC, display, and end-to-end system latency and notes that frame rate and latency are related but not equivalent.
Describe the input action and visible response used for the test. Record camera position, scene or replay, duration, warm-up, number of runs, network state, background tasks, and treatment of loading screens. If the result is subjective, label it as an observation rather than a measured duration.
Record every relevant setting
Capture the input device model, firmware, wired or wireless mode, polling choice when exposed, USB path, controller profile, dead zone, game input mode, display model, refresh rate, resolution, window mode, VSync, variable refresh, frame limit, render scale, upscaling, frame generation, low-latency options, power profile, driver, and OS build. Preserve a neutral text export or checklist in addition to screenshots.
Microsoft's Windows graphics settings overview explains that windowed-game optimizations can reduce presentation latency for eligible DirectX 10 and 11 games and that system-wide and per-application choices can differ. That is a useful example of a setting whose scope and override must be recorded.
Keep decisions and tradeoffs explicit
For each change, log the hypothesis, owner, old value, new value, test method, result, side effects, and rollback. A lower-latency mode can affect power, image quality, frame pacing, compatibility, or capture behavior, so write the accepted tradeoff rather than declaring one value universally best.
Apple's game graphics performance guidance recommends collecting time, frame and present timing, memory, and graphics-setting data, then profiling across the game and device classes. It also treats input latency and frame pacing as settings that should be tuned with other device features.
Assign ownership by layer
Name the owner for game code, input mapping, render settings, platform configuration, device firmware, display configuration, test tooling, release acceptance, and customer communication. A player-support owner may reproduce symptoms, while engineering owns measurement interpretation and a release owner accepts the tradeoff.
Record who can change each setting and where the authoritative value lives. Store no private account credentials in the benchmark packet. When a driver or platform update overrides a setting, document the observed change and retest instead of silently restoring an old value.
Make the test repeatable
Give another tester the build, saved scenario, configuration, input procedure, capture method, run count, tolerance, and raw-result location. Ask that person to reproduce both the baseline and one controlled change. Compare distributions or repeated runs rather than one favorable sample.
Review the document after hardware, display, driver, OS, game, controller, or measurement-tool changes. The record works when a qualified tester can explain what the latency number includes, reproduce it, identify the owner of each layer, and defend why the current settings were chosen.
Sources
- Introducing NVIDIA Reflex: Optimise and Measure Latency in Competitive Games — NVIDIA GeForce
- Navigating the Redesigned Graphics Settings page — Microsoft DirectX Developer Blog
- Improving Your Game's Graphics Performance and Settings — Apple Developer