Measuring your own latency
You do not need special equipment to find out where your latency is going. A phone that records at 240 frames per second, which most phones now do, measures your entire chain to within about 4 ms. Here is the procedure.
Method 1: the phone camera (free, end to end)
This is the only method that captures the entire chain including your peripherals and your display, and it costs nothing.
Setup
- Position your phone so that both your mouse (or your finger on it) and your monitor are visible in the same frame.
- Light the scene as brightly as you can. High frame rate recording needs short exposures, and short exposures need light.
- Set the phone to its highest slow-motion frame rate. 240 fps is common; 960 fps burst modes exist and are better if you can trigger them at the right moment.
Procedure
- Record. Perform an input with an unambiguous on-screen consequence: firing a weapon with a bright muzzle flash is ideal, because the change is large and instantaneous.
- Do it at least ten times in one recording.
- Step through the footage frame by frame. For each attempt, note the frame number where the mouse button visibly depresses, and the frame number where the screen first changes.
- Subtract, then convert.
Take the median of your ten attempts, not the best. The best is the one where your input happened to land at a favourable point in three different cycles, and it is not representative.
What the camera can and cannot see
It sees everything: switch, polling, radio, game, queue, scan-out, panel. It cannot tell you which stage is responsible, only the total. To attribute the total, change one variable at a time and re-measure. Turning Reflex on and off is usually the most informative single comparison.
Method 2: in-game and driver overlays
Nvidia's PC latency readout, similar AMD reporting, and some in-engine statistics show the portion of the chain from input received to frame presented. This excludes your peripherals and your display, which means it will always read lower than reality by 5 to 15 ms.
Used correctly this is a precision instrument for exactly one job: seeing what happens to your render queue when you change settings. Toggle Reflex, change a framerate cap, alter graphics settings, and watch the number. It updates in real time, which makes it far faster than the camera method for iterating.
Do not use it to compare a mouse or a monitor, because it cannot see either.
Method 3: hardware testers
Dedicated latency testers instrument the click directly and detect the screen change with a photodiode, giving sub-millisecond accuracy without a camera. Some monitors include a version of this built in, allowing an automated measurement with a compatible mouse.
These are worth it if you are comparing devices that differ by a few milliseconds. For finding and fixing your own configuration, they measure the same thing the camera does, more precisely than you need.
Interpreting your result
| Measured | Interpretation | Where to look first |
|---|---|---|
| Under 15 ms | Excellent. Well-configured high refresh setup. | Nothing. Go and play. |
| 15 to 30 ms | Good. Typical of a competent competitive configuration. | Optional: polling rate, framerate cap |
| 30 to 50 ms | Something is not configured. Usually the queue. | Reflex, framerate cap, polling rate |
| 50 to 80 ms | Multiple stages are poor. | Refresh rate and the render queue together |
| Over 80 ms | A 60 Hz display with an uncapped GPU-bound game, almost always. | Cap the framerate, then look at the display |
Related reading
- Predict the result before you measure it, then see how close the model was.
- The chain, to attribute what you measured.
- Reflex and Anti-Lag, the most informative single toggle to measure.
Frequently asked questions
How accurate is the phone camera method?
Your uncertainty is roughly one frame period, so about 4.2 ms at 240 fps and about 8.3 ms at 120 fps. That is coarse for comparing two mice and entirely adequate for finding a 30 ms render queue problem, which is what most people actually need.
What does the in-game latency overlay measure?
Typically from the moment the game receives the input to the moment the frame is presented to the display. It does not include peripheral latency (switch debounce, polling, radio) or display latency (scan-out, panel response). It is excellent for isolating the render queue and useless for evaluating a mouse.
Do I need a hardware latency tester?
Only if you are comparing devices whose difference is a few milliseconds, which is a reviewing task rather than a setup task. For finding and fixing your own bottleneck, the camera method plus an in-game overlay covers everything you need.
Why does my measured latency vary between attempts?
Because it genuinely varies. Where your input lands within a polling interval, within a frame, and within a refresh cycle are all effectively random, and together they contribute several milliseconds of spread. Take at least ten measurements and use the median.
What is a normal result?
On a well-configured competitive setup, 15 to 30 ms end to end. On a typical uncapped GPU-bound configuration at 60 Hz, 60 to 100 ms is common. If you measure over 80 ms, look at your render queue and refresh rate before anything else.