IP KVM Latency Benchmarks: Every Device Measured Glass to Glass (2026)

Updated October 20, 2026. These IP KVM latency benchmarks replace our July 2026 results. We rebuilt the rig, changed what the number measures, and re-ran every device on current firmware. The July figures are not comparable with these, and the section below explains what changed and why.

Disclosure: WarpKVM makes IP KVMs, and we measured our own two boards in this same test round: the same rig, the same checks and the same analysis as every other device. They are labelled as ours wherever they appear.

This round covers nine shipping IP KVMs and our two boards on one glass-to-glass rig. At 1080p60 in Chrome the fastest KVMs we tested were the Sipeed NanoKVM Pro (53.3 ms) and the GL.iNet Comet (54.1 ms), close enough to call a tie, and the slowest was the BliKVM v4 at 185.9 ms. Six of the nine landed within 8 ms of each other. The spread that used to define this category has mostly closed, and the differences that remain show up on scrolling text, at 120 Hz and at 4K.

The results at 1080p60

Every figure is the median glass-to-glass latency in Chrome, from 300 timed screen changes per side, at 1920x1080 and 60 Hz over wired gigabit LAN. We measure two kinds of picture. Scrolling text changes every frame, which is the hard case for an encoder and the one you feel while reading logs or scrolling a page. A still screen changes only in a small box, which is the easy case. The ranking uses the higher of the two, so no device gets credit for its best case alone.

The NanoKVM Pro and the Comet are 0.8 ms apart on scrolling text, and their 95 % confidence intervals overlap (52.4 to 54.8 ms against 53.1 to 55.4 ms), so treat them as tied. On a still screen the Comet is clearly faster at 42.1 ms. Our own boards are in the table because we said in July that WarpKVM would face the same rig and the same rules, and the disclosure at the end applies.

What the results show

The pack has closed up. With every device at its best settings and on current firmware, the NanoKVM Pro, both Comets, the PiKVM V4 Plus and the JetKVM all sit between 53 and 60 ms on scrolling text, and the TinyPilot is less than 2 ms behind them. For everyday administration those six feel alike, with one caveat: the TinyPilot has a long tail, with about a quarter of its measurements landing near 170 to 190 ms, so its slow moments are much worse than its median. The real separation is in the three that use slower paths: the PicoKVM at 90 ms, and the two MJPEG devices at 145 to 186 ms.

Scrolling text is where KVMs differ. On a still screen most devices only have to encode a small changed box, and the Comet drops to 42.1 ms. Make every frame change and the same Comet takes 54.1 ms, the NanoKVM Full goes from 87.1 to 144.8 ms, and the PicoKVM from 77.4 to 90.0 ms. A benchmark that only measures a still screen flatters exactly the devices that struggle when you scroll.

Settings decide the result more than the hardware does. The PiKVM V4 Plus at stock settings delivers 30 frames per second and measured 60.9 ms; with the H.264 boost it reaches 60 fps and 57.3 ms. The JetKVM at Quality High measured 63.1 ms on scrolling text and froze 15 % of frames, against 59.8 ms at Quality Low. The BliKVM's H.264 mode is software encoded and measured 688 ms on text, nearly four times its MJPEG figure. If you own one of these, the settings column in the table is worth copying.

Frame rate is part of latency. The TinyPilot Voyager 3 shows it directly. With its High-performance mode off it sends 30 fps and measured 68.1 ms; with the mode on it sends about 51 fps and measured 61.3 ms. At 30 fps a change can wait up to a full extra frame before it is sent. MJPEG devices avoid that by sending whole pictures, at a heavy bandwidth cost: 70 to 177 Mbps on scrolling text, where the H.264 devices used 1.7 to 16 Mbps.

Beyond 1080p60: 120 Hz and 4K

Higher refresh rates and resolutions separate the field far more than 1080p60 does, mostly because many devices simply cannot do them.

At 1080p120, viewed on a 120 Hz monitor, only three of the nine competitors delivered a measurable stream on both contents: the GL.iNet Comet Pro (32.2 ms text, 32.3 ms still), the Comet (32.8 and 33.8 ms) and the NanoKVM Pro (41.3 and 37.0 ms). Here the Comet Pro is a little faster than the base Comet, the one mode where it is. The BliKVM gave a still-screen figure of 86.6 ms but no usable text run. The JetKVM and the PicoKVM showed no picture at 120 Hz; the PiKVM at stock settings and the TinyPilot stalled at about one frame per second. The NanoKVM Full accepts 60 Hz input only.

To feel these gaps rather than read them, our latency page adds each measured delay to your own pointer, at 1080p60, 1080p120, 4K30 and 4K60.

At 4K30 only the 4K-capable devices were run. The Comet measured 80.3 ms on text and 74.0 ms still, and the Comet Pro 86.3 and 85.0 ms. The NanoKVM Pro was fast on a still screen (65.7 ms) but its scrolling text collapsed: 234.6 ms, with only 19 frames per second arriving and 57 % of frames frozen. Our monitors have no 30 Hz mode at 3840x2160, so the viewer runs at 60 Hz and we add back the extra delay the panel showed for a 30 Hz input, measured in each session (about 25 ms). At 4K60 no competitor delivered a picture: the NanoKVM Pro stayed at 1080p, and the GL.iNet units were run at 4K30 only.

What changed since July, and why

Our July benchmarks reported "click-to-photon" figures from a simpler rig. Those numbers were the best we could measure with what we had: a single OSLTT, about $200 of test hardware. The October rig costs roughly $1,350: two identical $400 monitors, two $200 OSLTT units, a $120 Rock 4D source board and a $35 HDMI splitter. That extra hardware is what lets us measure against a reference, take refresh timing out of the result and check every run. Here is what we changed and what each change taught us.

1. We measure against a reference monitor instead of subtracting a floor. In July one light sensor timed a click injected through the KVM's own USB mouse to the change on the client screen, and we subtracted a separately measured 14 ms floor. Now an HDMI splitter feeds the same picture to a reference monitor and to the KVM, and two light sensors take turns timing the same test box on each monitor, 300 times each. Everything outside the KVM, from the source to the panel, is identical on both sides and cancels in the difference instead of being estimated separately.
2. We stopped trusting refresh-timing luck. The viewer's monitor refreshes on its own clock, so a frame can wait anywhere from zero to a full refresh (16.7 ms at 60 Hz) before it is shown, and a run tends to sit at one point in that range for minutes. We found that our earlier runs each covered only a sliver of it. We now log the viewer's refresh timing for every measurement and balance the result over all of it.
3. We control the viewer PC. Windows draws browser windows at the refresh rate of the fastest monitor attached, so a PC with a high refresh monitor makes every browser-based KVM look faster. An idling graphics card can also hide about 13 ms. The viewer now drives one monitor at the tested refresh rate, and every run checks that the graphics card is at full clock at its start and end.
4. Best settings, not defaults. July measured each device as it came out of the box. That told you more about default choices than about hardware: as we found them, the PiKVM was set to 30 fps and the TinyPilot to MJPEG. Now every device is set to its lowest-latency mode, the way an owner could set it, and the runner reads the settings back and records them with the result.
5. Two kinds of picture. July used a full-screen flash. We now run scrolling text and a still screen, and rank on the slower of the two.
6. Current firmware. Five of the devices were updated to their latest firmware on October 19, before testing, and every result records the firmware it ran.
7. Confidence intervals. Each side gets 300 measurements and every figure has a 95 % confidence interval, so two devices within noise of each other are reported as a tie.

The input path, your click travelling through the KVM to the target, is no longer in the number. It deserves its own test, and until we have one we do not publish click-to-photon figures. The full procedure is in our glass-to-glass test method.

Because the two methods measure different things under different rules, the July figures are not comparable with these, and we have retired them. The NanoKVM PCIe from the July set was not part of the October run, so we no longer publish a figure for it.

Where our own time goes

We can only instrument our own boards, so this part is about WarpKVM alone. On a separate run on October 17 we timestamped every stage inside both boards, in the WarpKVM app on scrolling text. At 1080p60 about four fifths of the total is two waits set by the refresh rate: the rest of the HDMI frame arriving, and the viewer monitor's next refresh. The KVM pipeline itself took 4.8 ms on the WarpKVM 01 and 3.2 ms on the DIY kit, and at 1080p120 both refresh waits halve. How every glass-to-glass number breaks down is explained in our test method.

Where our figures stop

Our boards lead every mode we measured, so it is worth being plain about what that does and does not show.

• Every competitor here ships today. Our boards are pre-release. The DIY kit and the WarpKVM 01 are pre-orders, measured on our own units.
• Our 4K figures are from the WarpKVM app, not Chrome. The competitors' 4K30 figures are in their browser players, so any 4K comparison is our app against their browser. We have not yet measured the WarpKVM 01 in Chrome at 1080p120 either.
• PiKVM's software is more mature than ours, with years of development and a far larger community behind it. Latency is one reason to choose a KVM, not the only one.

The device-by-device picture

• Sipeed NanoKVM Pro (53.3 ms): joint fastest at 1080p60 and identical on both contents, but its 4K30 scrolling text falls apart at 19 fps. See the NanoKVM review.
• GL.iNet Comet (54.1 ms): joint fastest, the fastest on a still screen (42.1 ms) and the fastest competitor at 4K30. At 1080p120 it is about 1.5 ms behind the Comet Pro. In our early runs its browser player was also faster than GL.iNet's own desktop app. Full detail in the Comet review.
• GL.iNet Comet Pro (57.3 ms): a little slower than the base Comet at 1080p60 and 4K30, but the fastest competitor at 1080p120 (32.3 ms).
• PiKVM V4 Plus (57.3 ms): only with the H.264 boost; at stock it sends 30 fps and measured 60.9 ms. See the PiKVM review.
• JetKVM (59.8 ms): at Quality Low it is right with the pack, at very low bandwidth (1.7 Mbps on scrolling text). See the JetKVM review.
• TinyPilot Voyager 3 (61.3 ms): with its High-performance mode on it delivers about 51 fps and lands just behind the JetKVM, but about a quarter of its measurements took 170 to 190 ms. Turn the mode on; it was off on our unit as we found it. See the TinyPilot review.
• Luckfox PicoKVM (90.0 ms): usable, but the slowest of the devices whose best mode is H.264, and the High quality setting it came set to froze 13 % of frames on scrolling text.
• Sipeed NanoKVM Full (144.8 ms): MJPEG is its complete best mode. Its H.264 mode was faster on text (128.7 ms) but on a near-static screen the encoder dropped to about 5 fps and the browser fell about a second behind.
• BliKVM v4 (185.9 ms): MJPEG at 30 fps for text; at 60 fps it needs about 94 Mbps and the browser could not keep up. See the BliKVM review.

The verdict

FAQ

FAQ

What is the fastest IP KVM?

Of the nine shipping KVMs we tested in October 2026, the GL.iNet Comet and the Sipeed NanoKVM Pro tied at 1080p60 in Chrome (54.1 and 53.3 ms glass to glass on scrolling text). The Comet was faster on a still screen and at 4K30; at 1080p120 the Comet Pro was fastest (32.3 ms). Our own WarpKVM boards measured 32.4 to 40.2 ms in Chrome, but they are pre-release.

What is glass-to-glass latency?

It is the time from a change appearing on the source machine's screen to the same change appearing on your viewer screen. We measure it by showing the source on a reference monitor and through the KVM on an identical monitor, then timing a test box changing on each with light sensors and taking the difference. It covers capture, encoding, the network, decoding and display, but not your mouse click reaching the target.

Why are these numbers different from your July benchmarks?

We changed what we measure and how. July timed one sensor from an injected click and subtracted an estimated floor, at default settings. October compares against a reference monitor, balances out refresh-timing luck, controls the viewer PC, and runs every device at its best settings on current firmware. The two sets are not comparable.

How much latency is acceptable for a KVM over IP?

For BIOS work and server administration, anything under about 100 ms is comfortable, and seven of the nine shipping KVMs we tested met that at 1080p60. For scrolling, editing and general desktop use, the 50 to 60 ms group feels noticeably more direct than the MJPEG devices at 145 to 186 ms.

Disclosure

Every figure here was measured on our own bench between October 16 and 20, 2026: 1920x1080 at 60 Hz unless stated, two LG 27G810A monitors, Chrome on Windows 10 over wired gigabit LAN, the median of 300 measurements per side, and each competitor at its lowest-latency settings on current firmware. The full procedure is in our test method and how we test IP KVMs. This page is published by WarpKVM, which makes IP KVMs of its own. Our boards were measured on the same rig with the same checks, and our figures are labelled wherever they appear.