Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

To me the question is how do you use that method to measure keyboard responsiveness? On the camera, you can't quite tell when the key was "supposed" to trigger. I've done these measurements by having a keypress toggle an LED on the keyboard (in firmware), but that glosses over the matrix scan (and potentially debouncing if you implement that wrong). All in all, I've never been fully satisfied there. Maybe you need a one-key keyboard that triggers the LED from an interrupt, and then handles the keypress normally. (Only one key, so no matrix. Triggers on the first edge, so no debounce latency.)


NVIDIA published LDAT[1] for click-to-photon latency measurements a while ago. The 'Intended' purpose was to measure input latency for gaming but it could probably be reused for measuring responsivity. This would implicitly also measure the hardware but that shouldn't matter when a constant hardware/driver combo is used.

[1]: https://www.nvidia.com/en-us/geforce/news/nvidia-reviewer-to...


AFAIK you'd have to have a pretty bad keyboard for it to have a significant role in latency. I guess specialized hardware (based on a microcontroller with built-in USB host support) wouldn't be too hard to construct if you really needed to know.

For the camera measurement, I would just press the key as fast as possible and pick about 3/4 of the way down as the trigger point.


> AFAIK you'd have to have a pretty bad keyboard for it to have a significant role in latency

https://danluu.com/keyboard-latency/ puts a lot of keyboards >= 30 ms which is an insane amount of latency


So if you check the appendix section, they say they're measuring latency not when the keyswitch makes contact, but when the finger first begins pressing on the key. So they're taking key travel time into account, and that ends up being the majority of the "latency".

It's a fair point for the gaming argument they make, if you want to jump 30ms quicker you'll need shorter keys. But it's not really correct to say the keyboard is adding so much latency when it's actually the user.


> So if you check the appendix section, they say they're measuring latency not when the keyswitch makes contact, but when the finger first begins pressing on the key. So they're taking key travel time into account, and that ends up being the majority of the "latency".

The key travel time on https://www.amazon.com/gp/product/B0000U1DJ2/ and https://www.amazon.com/gp/product/B00DGJALYW is substantially the same, yet one has 20 ms of latency, and the other 55 ms.


I built one! Arduino Leonardo and a light dependent transistor:

https://github.com/willmuldrew/lagmeter

(It attempts to do a few other things but it’s best for measuring keyboard event to screen update latency)


What about fpga which issues a (fake) ps2 keypressed signal and synchronous trigger (led in this case) for the camera?


Or use the caps lock key and have that reflected on screen.


Is the caps lock LED even implemented in hardware? I feel like I remember them not responding if my computer freezes but I could be wrong.


I can confirm the LED is not controlled by only keyboard firmware.

I very often use num lock and caps lock responsiveness to check if my PC has hard-locked, and I just recently suffered hard locks while testing S3 on Linux on a new PC. So I am very sure at this point :)


I only really suggested that because any OS can detect the presence of the CAPS LOCK key (see 'CAPS LOCK is on' during Windows login) and it would make a potentially good marker.


Caps lock doesn't magically skip the matrix scan.


Nothing on the keyboard does. I'm trying to suggest an alternative that already has visual feedback.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: