系统与基础设施danluu.com
键盘延迟
Keyboard latency
2017 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章实测并比较了多款键盘的输入延迟，分析按键行程、键盘扫描与去抖动、USB 轮询，以及操作系统和软件路径各自对延迟的贡献。作者还讨论了“现代键盘是否比旧键盘更慢”这一问题，并给出不同键盘的延迟数据。
为什么经久不衰：键盘延迟是每天都能感受到却常被忽视的体验问题，文章用可复现的测量和大量设备数据把从硬件到软件整条链路讲清楚，多年后仍有参考价值。
HN 评论精选
人类能明显感知 100ms 级的输入延迟，反应时间与感知延迟是两回事。
我很惊讶居然还有人提出“人类注意不到 100 毫秒”这种论点。用命令行做个简单的盲测就能轻易反驳：对比 `sleep 0.1` 和把 `sleep` 别名成 `true`。在我看来，100ms 的延迟很明显，50ms 能感觉到，20ms 勉强可察觉，10ms 就察觉不到。更别说 100ms 在音乐上是 150 bpm 的十六分音符；即使在这个速度下，偏差一个十六分音符——尤其对打击乐器——也很明显。另一方面，如果要求我在视觉刺激后不到 100ms 内按键，我肯定做不到——那才是“反应时间”。
colanderman查看英文原文
I'm surprised the "humans don't notice 100 ms" argument is even made. That's trivially debunkable with a simple blind A/B test at the command line using `sleep 0.1` with and without `sleep` aliased to `true`. To my eyes, the delay is obvious at 100 ms, noticeable at 50 ms, barely perceptible at 20 ms, and unnoticeable at 10 ms. Not to mention that 100 ms is musically a 16th note at 150 bpm. Being off by a 16th note even at that speed is – especially for percussive instruments – obvious. On the other hand, if you told me to strike a key less than 100 ms after some visual stimuli, I'm sure I couldn't do it – that's what "reaction time" is.
延迟应从开关激活或触觉反馈算起，而非从按键行程起点算起。
我认为更好的测量方式是从开关激活那一刻算起，而不是从按键行程开始。我不是从开始按下那一刻就等待字符出现；我的预期始于我感觉到开关触发的触觉反馈（对于没有触觉反馈的开关，则是触底）。在有良好触觉反馈的键盘上，我可能不会把开关按完全行程，只在触发点和复位点附近小幅移动。
korethr查看英文原文
IMO, a better measure would be from activation of the switch, as opposed to the beginning of key travel. I don't start waiting for the character to appear on my screen from the moment I begin to press down. My anticipation begins when I feel the tactile feedback of the switch activating (or the switch bottoming out on switches that don't offer tactile feedback). On a keyboard with good tactile feedback, I might not move the switch through it's full travel -- just a little bit above and below the activation and reset points.
音乐键盘证明矩阵扫描和去抖动可做到低于 2ms，10ms 以上的延迟并非不可避免。
对比音乐键盘：不仅按键编号重要，力度也重要，所以每个键有两个电触点，整个扫描通常约 10kHz 以正确测量力度。尽管触点排成二极管矩阵，延迟通常低于 2ms，即使老式 MIDI 也是。所以键盘矩阵和去抖动都不能解释 10ms 或更高的延迟。很高兴看到延迟现在在游戏中成为问题，类似实时音频，大多数操作系统仍不太可用——OS X 除外。
Stenzel查看英文原文
Compare with musical keyboards where not only key number but also the velocity matters, so each key has two electrical contacts, and the whole thing is usually scanned around 10kHz for proper velocity measurement. Although key contacts are arranged in a diode matrix, the latency is usually below 2 ms, even with good old MIDI. So neither the keyboard matrix nor the debouncing justify a latency of 10 ms or above. It is nice to see that latency is an issue in gaming now, similar to realtime audio, where most operating systems are still not very usable - with the exception of OS X.
同一台 Mac 上，图形栈和帧缓冲会显著增加输入延迟，单用户模式仅 37.5ms。
我用 MacBook Air 和“Is It Snappy”应用做了简单测试，用的是 MacBook 的巧克力键盘。除了 TextEdit（只测两次），其余都测三次。TextEdit：从按下键到 LCD 像素开始变化约 81ms；Sublime Text 约 86ms，两者很接近。但如果启动到 macOS 恢复模式，可以进入没有垂直同步/三缓冲帧缓冲的 GUI：恢复模式终端约 57ms。最后是杀手锏：macOS 用户一直可以在启动时进入单用户模式：37.5ms（三次测量完全相同）。想体验旧电脑打字的延迟感，重启 Mac 并在启动时按住 Command+S。
rubatuga查看英文原文
I've done a simple test with my Macbook Air, using the app "Is It Snappy", as mentioned in the comments. I used the keyboard on my macbook, which is a chiclet style mechanism. The tests were all done in triplicate except for TextEdit, (only twice) TextEdit: ~81 ms from key depression to when LCD pixels begin to shift. For Sublime Text: ~86 ms. Both of these text editors are pretty well matched. However, if you boot into Recovery Mode in macOS, you gain access to a GUI without a V-synced/tripled framebuffer. Terminal in Recovery Mode: ~57 ms Finally, the kicker. macOS users have always had access to a terminal interface upon boot called single-user mode: Single User Mode: 37.5ms (all three measurements were the same) If you want to experience what the latency on old computers felt like while typing, simply reboot your mac, and while it's starting up, hold 'Command + S'!
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选