The OSLTT KVM Latency Test: How We Measure Glass-to-Glass

An OSLTT KVM latency test measures how long a KVM over IP takes to show a change from the source machine on your screen. We run it glass to glass: one HDMI source feeds a reference monitor directly and a viewer monitor through the KVM, and two OSLTT-based light sensors time the same test box on each. The difference is the latency the KVM path adds.

This page documents that method in full, because a benchmark you cannot inspect is a benchmark you cannot trust. Every latency figure in our reviews and in our IP KVM latency benchmarks comes from this rig, under these rules.

Updated October 20, 2026. Until October this page described a click-to-photon test: one sensor on a client laptop, a click injected through the KVM's emulated mouse, and a display floor subtracted afterwards. We replaced it. Building a stricter rig showed us that the old setup let refresh timing, the viewer PC and default settings move results by more than the gaps between some devices. The last section explains each lesson.

What glass-to-glass measures, and what it leaves out

Glass-to-glass latency is the time from a change appearing on the source's own screen to the same change appearing on the screen you view the KVM on. For an IP KVM that covers HDMI capture, encoding, the network, decoding in the browser or app, and the viewer's display. It is what you notice when you scroll a log, drag a window or watch a boot screen. Our latency page lets you feel the figures this rig produces by adding each one to your own pointer.

We dropped the input path on purpose. Timing a click through the KVM mixes two different systems, video and USB input, into one number, and in our old rig the input side was the least controlled part. The video path now gets a rig built for it. Input latency will get its own test, and until it does we publish no click-to-photon figures.

The rig

• The source is a small single-board computer (a Radxa Rock 4D) running a test program that paints a large box, flipping it between black and white, and logs exactly when in the frame every paint lands. Behind the box it draws either a still background or scrolling text.
• An HDMI splitter (OREI UHDS-104) sends the identical signal to two places: straight to the reference monitor, and into the KVM under test.
• The KVM captures, encodes and streams over wired gigabit LAN, through the same switch path for every device.
• The viewer PC (Windows 10, NVIDIA RTX 2060) shows the KVM's stream full screen, in Chrome or in the vendor's own app, on the viewer monitor.
• The two monitors are the same model (LG 27G810A) with the same settings. A hooded light sensor is taped at the same spot on each, over the centre of the box.
• Two light sensors, OSLTT units (the open-source latency tester by TechteamGB), one on each monitor. Each only reads the brightness change of the box on its own screen and reports the timing to the source over USB. They run our own test firmware, which adds the serial commands the runner needs. Full credit for the OSLTT hardware goes to its author.

Because the reference side and the viewer side share the same source, the same paint and the same model of monitor, all of those cancel when we subtract one from the other. What is left is what the KVM path adds over a direct cable.

The method, step by step

1. Step 1

   Set the device to its best settings

   Each KVM is set to its lowest-latency mode, the way an owner could set it in its own interface: for example Quality Low on the JetKVM, Lowest Latency on the GL.iNet units, the H.264 boost on the PiKVM. The runner then reads the settings back from a fresh session and saves a screenshot with the result.

2. Step 2

   Measure a start baseline

   Both monitors are switched to the splitter, so there is no KVM in either path. The two sensors should read within 10 ms of each other. That small offset between the monitors is recorded and removed from every result.

3. Step 3

   Run the checks

   Before the timing starts, the runner confirms the viewer is showing the KVM and not the splitter, the stream is at the source's resolution, the colours are correct, the player is full screen with nothing drawn over it, and the viewer's graphics card is at full clock. A failed check fails the run.

4. Step 4

   Time 300 changes per side

   Each side times 300 box changes, split evenly between black-to-white and white-to-black so panel rise and fall times balance out. Gaps between changes are random, 400 to 900 ms, so they land at every point of the source, encoder and display cycles. A change only counts once the sensor has settled.

5. Step 5

   Measure an end baseline

   The baseline is repeated after the run. If it drifted more than 0.5 ms from the start, the run is void.

6. Step 6

   Compute the result

   Viewer median minus reference median, minus the baseline offset, balanced over the viewer monitor's refresh timing. Each figure is reported with a 95 % confidence interval from resampling both sides.

Two kinds of picture

We measure every configuration twice. On a still screen only the box changes, so the encoder has very little to send. With scrolling text behind the box, every frame changes, which is the hard case and the one you feel while scrolling. Some devices are barely affected; others slow down a lot (the GL.iNet Comet goes from 42.1 to 54.1 ms, the NanoKVM Full from 87.1 to 144.8 ms). We report both and rank on the slower of the two, so no device is ranked on its easy case.

Taking refresh-timing luck out

The viewer's monitor refreshes on the viewer PC's clock, not the source's. A decoded frame waits for that monitor's next refresh to reach the sensor's row, which can be anything from zero to a full refresh: up to 16.7 ms at 60 Hz. The two clocks drift against each other very slowly, so a single run can sit at one point in that window for many minutes, and its median lands wherever luck put it.

Every glass-to-glass number is made of three parts. First, the frame has to finish arriving over HDMI, because a KVM cannot capture a frame until all of it is in. Then comes the KVM's own work: capture, encode, the network and decode. Last, the finished frame waits for the viewer monitor's next refresh. The first and last parts are set by the refresh rate, so at 120 Hz both halve and the total should drop. It only does if the encoder keeps up with twice as many frames. In our October tests, three of the nine KVMs we compared delivered a usable 1080p120 stream; two showed no picture and two stalled at about one frame per second.

We fix this two ways. The viewer is set 0.1 % slower than the source (59.94 Hz against 60 Hz), so the timing between the two clocks sweeps through the whole window every 16.7 seconds and a run covers it about 20 times. A logger on the viewer PC also records each refresh, and the analysis sorts every measurement into eight timing bins and weights them equally. The source side gets the same treatment from the source's own paint log.

Higher refresh rates and 4K

• 1080p120 is only ever measured with a 120 Hz source and a 120 Hz viewer, and only compared with other 120 Hz results.
• 4K30 has no matching mode on our monitors, which offer no 30 Hz at 3840x2160. The viewer runs at 60 Hz, and the extra delay the monitor adds to a 30 Hz input is measured in each session (about 25 ms) and added back. Without that correction a 4K30 figure would look about 25 ms better than it is.
• 4K60 is measured directly, when a device can deliver it.

The statistics we report

• 300 timed changes per side, after a warm-up that is thrown away, with a fresh start and end baseline for each mode.
• Median with a 95 % confidence interval. Two devices whose intervals overlap are reported as a tie, not ranked.
• Nothing is trimmed. A measurement is excluded only for a mechanical reason (no detection, the sensor had not settled, or the source logged no flip), and the count is kept. A side with more than 2 % invalid measurements voids the run.
• Stream statistics recorded from the player in Chrome: frames per second delivered, the share of frames frozen, and the longest freeze. MJPEG players do not expose these, so for them we record bandwidth only.

What this rig does not measure

• The input path. Your click going through the KVM to the target is not in the number.
• Your network. Everything runs on wired gigabit LAN, so the figures are the device's floor. Wi-Fi, VPNs and long internet paths add to them.
• Other viewer PCs. We use one Windows 10 PC with one monitor. A faster monitor shortens the refresh wait for every KVM, and a slower graphics card lengthens decode.
• Picture quality. Frozen-frame counts are recorded, but quality has its own comparison.

What we learned moving from click-to-photon

The July rig was a reasonable first build: one OSLTT on a client laptop, clicks injected through the KVM's own mouse, 1,000 samples per device, and a 14 ms display floor subtracted. Putting a second, identical monitor next to it taught us how much that setup could not see.

1. A floor measured separately does not cancel cleanly. The 14 ms floor came from a different run, on a different path, at a different moment. A reference monitor on the same splitter cancels the source, its paint and the panel inside every measurement instead.
2. Refresh timing can move a result by most of a frame. Our first two-monitor session showed the same KVM reading 22.1 ms on one content and 30.7 ms on another, largely because the two runs sat at different points of the viewer's refresh window. With refresh timing balanced, the same path now measures 23.4 and 22.6 ms.
3. The viewer PC was part of the result. Windows draws browser windows at the refresh rate of the fastest monitor attached, so a PC that also drives a high refresh monitor makes every browser-based KVM look faster. A graphics card idling at a low clock hid about 13 ms. The viewer now drives one monitor, and its clock is checked at the start and end of every run.
4. Defaults measure defaults. As we found them, the PiKVM was set to 30 fps and the TinyPilot to MJPEG, so July measured those choices more than the hardware. Every device now runs at its lowest-latency settings, read back and recorded.
5. A full-screen flash is the easy case. Scrolling text exposes encoders that a static flash does not.

None of this made the July figures dishonest, but together these effects were larger than the differences between several devices, which made the ranking unreliable. The benchmarks page shows the old and new figures side by side.

Run it yourself

The parts are off the shelf: two identical monitors, an HDMI splitter, a source you can program to flip a box and log its paint timing, and two light sensors. OSLTT is open hardware you can build from the project or buy from its maker. Measure a baseline with both monitors on the splitter, then put the KVM in one path and subtract. If your numbers disagree with ours, tell us why. We keep the raw records for every figure we publish.

FAQ

FAQ

What is the difference between glass-to-glass and click-to-photon latency?

Glass-to-glass times the video path: from a change on the source's screen to the same change on your viewer screen. Click-to-photon adds the input path, your click travelling through the KVM's emulated USB to the target. We publish glass-to-glass, because it can be measured cleanly against a direct cable.

Why use two monitors instead of one?

The reference monitor shows the source straight off a splitter, so the source, its paint timing and the panel are identical on both sides and cancel when we subtract. One monitor needs a floor measured separately, which never cancels as cleanly.

Do you test KVMs at their default settings?

No, not since October 2026. Every device is set to its lowest-latency mode in its own interface, the settings are read back and saved, and they are listed next to each result. Defaults often favour picture quality and can cost a device 10 ms or more.

Does a faster monitor lower KVM latency?

Yes, for every KVM. The viewer's monitor adds a wait of up to one refresh, 16.7 ms at 60 Hz and 8.3 ms at 120 Hz. That is why we only compare results measured at the same viewer refresh rate.

OSLTT is open-source hardware by TechteamGB; our testers are built on it and run our own test firmware. This page is published by WarpKVM, which makes IP KVMs of its own and measures them on this same rig, with the same checks.