Input lag is not a feature that simply works or fails. It is elapsed time across an input device, operating system, game or application, rendering pipeline, display, and sometimes the measurement tool itself. A useful test first defines which interval matters, then collects repeatable observations under a controlled configuration. Frames per second and subjective feel can help diagnose a result, but neither proves end-to-end latency by itself.
Define the start and finish of the measurement
Write the measurement boundary in plain language. It might be physical mouse switch to the first changed pixel, controller input to a camera movement, keyboard press to a UI response, or application input receipt to frame presentation. Record whether the number includes peripheral delay, PC processing, render queue, scanout, and display response.
NVIDIA's system latency guide separates peripheral, PC, and display components and recommends starting with end-to-end system latency before using narrower measures for diagnosis. Do not compare an end-to-end result with a render-only counter under one generic “latency” label.
Choose a tool that matches the boundary
The NVIDIA Latency Display Analysis Tool uses a luminance sensor to measure a physical action to a visible brightness change, such as a click to muzzle flash. NVIDIA describes it as cross-platform hardware that can work with GPUs from multiple vendors. A high-speed camera, photodiode setup, supported display analyzer, or carefully instrumented application can serve other boundaries, but each method needs its own uncertainty statement.
NVIDIA's Reflex platform overview explains that frames per second represents throughput rather than complete system latency and that a configured Reflex Analyzer can include mouse, PC, and display contributions. Treat vendor counters according to their documented scope. Do not present an overlay's render latency as click-to-pixel latency.
Freeze the test configuration
Record the computer, processor, graphics card, driver, operating system build, display model, refresh rate, resolution, connection, overdrive mode, adaptive-sync setting, input device, polling rate, game version, scene, graphics settings, frame cap, low-latency features, background workload, and power mode. Photograph or export important settings where practical.
Use a stable training area, replay, or invented test scene when the application permits it. Warm the system until clocks and temperatures settle. Restart between configurations when the changed setting requires it. Disable unrelated overlays only if that mirrors the intended operating setup, and document every exclusion. The result should describe a real configuration someone could reproduce.
Collect enough samples to see variation
Automate or standardize the input when possible. Otherwise use a fixed position and cadence, reject only observations covered by a written rule, and keep the original log. Collect repeated samples across more than one run. Report the sample count, median, a tail measure such as the 95th percentile, range or dispersion, and visible outliers. The single fastest click is not representative.
Randomize or alternate A and B configurations when heat, learning, or server state could bias a sequential test. Repeat on another day if the claimed difference is close to the measurement noise. For online play, separate local system latency from network and server delay; a local click-to-pixel tool does not measure matchmaking, packet loss, or remote simulation.
Use supporting metrics without changing the claim
Capture frame rate, frame-time distribution, one-percent-low performance, CPU and GPU utilization, clocks, temperature, power, and dropped or repeated frames. These values can explain a latency shift. They are not interchangeable with the primary latency measurement. A setting that lowers a mean by a small amount but causes severe stutter, tearing, visual artifacts, instability, excessive power, or worse tail latency may not be an improvement.
Include visual quality and gameplay consistency in the guardrails. Verify the same resolution, scene, game state, and input path. Check whether frame generation, upscaling, buffering, vertical synchronization, or a frame cap changes what the counter includes. State when a result applies only to one supported title or one tool integration.
Compare against a declared requirement
“Working as intended” needs an acceptance rule written before the result is known. That rule may be no regression beyond measurement uncertainty, a reproducible improvement from a named baseline, or a maximum latency under a specific use case. Use a practical threshold and include tail behavior rather than declaring success from a statistically detectable but irrelevant difference.
Save raw observations, configuration files, tool and firmware versions, screenshots, scripts, analysis method, summary statistics, exclusions, and hashes where useful. Re-run a known baseline after the experiment to detect drift. The final statement should name the boundary, configuration, method, sample size, central and tail results, uncertainty, and limitations. That makes input-lag evidence auditable instead of turning one smooth-feeling session into a universal claim.
Sources
- NVIDIA Latency and Display Analysis Tool — NVIDIA Developer
- NVIDIA Reflex Low Latency Platform — NVIDIA
- System Latency Optimization Guide — NVIDIA