How We Test IP KVMs: Our Rig, Protocol, and Data

A KVM test methodology is the fixed, published procedure a reviewer uses to measure an IP KVM: the hardware rig, the signal path, the instruments, and the way results are recorded. It matters because latency, power and image-quality numbers are only comparable between devices when the bench behind them does not change.

Everything we publish about how we test IP KVMs comes down to one principle: the same rig, the same method, applied identically to every device, with the raw data shown. Most KVM coverage is vendor spec sheets and subjective impressions. Ours is measured, and this page is the full disclosure of how, so you can judge the numbers for yourself and, if you want, reproduce them. It also commits us to something: our own upcoming device faces the exact same bench, held to the exact same method.

Why we publish the method

A benchmark you cannot inspect is a benchmark you cannot trust. Vendors quote encode times that ignore the network and the display; reviewers quote feelings. We wanted numbers that are objective, comparable across devices, and honest about their limits. That means disclosing the rig, the sample sizes, the baselines we subtract, and the cases where a measurement is approximate. The four things we measure, latency, power, video quality, and internals, each have a dedicated protocol, linked below in full.

The bench, in one picture

Every device is tested on one fixed rig so nothing varies but the KVM:

• A target machine with a discrete GPU drives the HDMI the KVM captures, so the source signal is clean, capable, and identical for every device. No KVM is advantaged or handicapped by a weak source.
• The KVM under test captures that HDMI and emulates the keyboard and mouse, connected over a wired LAN to hold the network constant.
• A client laptop displays the KVM's stream in a browser, where we place instruments and take measurements.

Fixing these variables is the whole point: when only the KVM changes between runs, the differences we measure belong to the KVM.

Both instruments are off-the-shelf, deliberately, so anyone can rebuild this bench. Latency is timed with OSLTT, an open-source click-to-photon tool built by TechteamGB and sold as a hand-built unit, and power is logged with an inline FNIRSI USB meter. We use OSLTT as it ships and publish no firmware of our own, so there is nothing bespoke in the measurement path to take on trust.

What we measure, and how

1. Step 1

   Latency (click-to-photon)

   An OSLTT light sensor times from an injected click to the pixel changing on the client screen: capture, encode, network, decode, display, all of it. 1,000 samples per device at 1080p60 over wired LAN, median reported, with a 14 ms display floor subtracted to isolate the KVM. Full protocol in our OSLTT rig writeup; results in the latency benchmarks.

2. Step 2

   Power draw

   A FNIRSI USB meter inline on the power feed logs voltage and current at 50 Hz. We mark startup and streaming phases separately and report average watts (not energy, which depends on run length) plus the peak for power-supply sizing. Full protocol in our power method writeup.

3. Step 3

   Video quality

   We send an identical test pattern through every device and capture lossless client-side screenshots, then compare matched crops to expose banding, chroma bandwidth, and range clipping per device. Results in our video-quality comparison.

4. Step 4

   Internals (teardown)

   We open every device and cross-check it three ways: physical chip markings, live register reads over a root shell, and the running kernel, until we have a verified bill of materials. Full protocol in our teardown method writeup.

The detail pages

Rather than bury the protocols here, each lives in full on its own page so this stays a readable overview and the methods stay reproducible:

• Our OSLTT latency rig: the click-to-photon setup, injected clicks, the display-floor subtraction, and the mouse constant.
• How we measure power: the FNIRSI setup, startup-versus-streaming segmentation, and why we report watts.
• Our teardown method: opening without damage, reading chip markings, and decoding storage registers into a verified BOM.

And the results those methods produce:

• IP KVM latency benchmarks: every device's measured click-to-photon latency.
• Power consumption compared: streaming, startup, and peak watts.
• Video quality compared: matched crops across the fleet.
• The capture chip database and storage provenance report: what the teardowns found.

The rules we hold ourselves to

A method is only as good as its honesty, so a few standing commitments:

• Identical conditions. Same source, same network, same client, same settings class for every device. When a device cannot be set to a comparable mode, we say so.
• Real sample sizes. Latency medians come from 1,000 samples, not a hand-picked best run, and we show the spread, not just the median.
• Disclosed baselines. We state exactly what we subtract (the display floor) and add (the mouse constant), so nothing is hidden in the arithmetic.
• Honest caveats. Where a reading is approximate, for instance a device that draws part of its power from the target, we flag it rather than pretend precision.
• Defaults first. We report out-of-box configuration, because that is what you actually get, then note where tuning helps.

The commitment

The reason to publish all of this is accountability. Any vendor can claim a latency figure; few will tell you how they got it or let you check. By showing the rig, the samples, and the baselines, we make our numbers falsifiable, which is the only kind worth trusting. And when our own device ships, it goes on this same bench, with the same 1,000-sample runs and the same disclosed baselines as everything else. No home-field advantage. The data starts with the latency benchmarks.

This page describes our own test methodology in full so the results across our reviews can be reproduced and challenged. Disclosure: it is published by WarpKVM, which is developing an IP KVM of its own and holds it to the same rig.