Thank you! I was really worried about the tone being too harsh or know-it-all. Wasn't really meant for audiences that weren't aware of the context. But as an emulator author, you get people presenting new zany latency reduction ideas that defy the laws of physics all the time, and they completely dismiss your own experience in the field, and it's like kids constantly saying, "are we there yet?" on a long car ride. Eventually you lose your cool, and then well ... you sound like me in that article >_>

> why bother polling the hardware at 1kHz? Is it a just-in-case solution to increase hardware polling to maximum?

Yes, pretty much. More of a because-we-can and to combat the cumulative effects of latency (death by a thousand papercuts) however possible. If you were to push it to 200Hz (5ms), then it becomes possible that your OS API returns states immediately after and it stacks with your emulator latency of 5ms to form a 10ms latency. Push it to 1000Hz and that drops to a 6ms maximum latency.

It is indeed silly. No one is going to perceive a worst-case 4ms difference. (And I say worst-case because these sorts of misses tend to average between best-case and worst-case, so in practice it's probably half that bad.)

We're trying to chase the emulation latency of a gamepad that you literally tell it exactly when to poll the inputs and within mere cycles on a 21MHz clock, start reading out the results from its shift-register.

> I'm also curious if there are any harder numbers available

That would be fun. I'll admit that many of the numbers are estimated. In the end, we can only observe the net total of all latency by pressing a button and seeing how quickly the sprites respond visually and aurally. But it's probably possible to isolate similar test cases for each source of latency. In a lot of cases (kernel audio mixing, keyboard responses), we're probably talking much smaller latencies than CRT vs LCD monitors, so you'd need a huge amount of precision.