The 16ms is for USB in legacy mode, where the BIOS does the USB stack handling and then provides the keyboard input via interrupt 60h to the OS. This is NOT ho

The 16ms is for USB in legacy mode, where the BIOS does the USB stack handling and then provides the keyboard input via interrupt 60h to the OS. This is NOT how a USB keyboard should be attached to any OS, and it hasn't been for at least a decade. Modern OSes have native keyboard drivers which integrate USB keyboards like any other USB device and speak to them directly, thereby bypassing that BIOS logic that introduces the delay. Such a driver is then capable of receiving key input with the delay depending on the USB bus delay. That is way shorter than 16ms, but also kind of hard to determine, because with USB being a host-controlled and shared interface, it basically depends on a) whether there is any other device also communicating and b) on the rate by which the host polls the device for new data. As far as I know, the latter is configurable (by the device and/or the driver, I'm unsure about that) within certain intervals, and it is possible to poll a keyboard at 1000Hz or even faster, so we're back at a theoretical delay of about 1ms - however, this time that's for the entire byte sequence belonging to a key press/release, not just for one byte as with the PS/2 keyboard, so this delay can directly be translated to keys pressed - no scancode sequences of differing length to account for.