Windows UI processing is very complex. It includes algorithms like priority promotion on keypress, but it will usually wait until the next scheduler ticklet (at worst, 30ms on desktop systems and 60ms on server systems) if another process asks for a full CPU cycle,
To overcome that, you would need a special keyboard driver that would provide event at the same latency, but also measure the accurate time. Accurate time measurement is possible on windows systems if dynamic CPU clock switching is disabled (Lookup entry QueryPerformanceCounter(), you would need to know how to invoke it from DDK), in which case, the keyboard event would still arrive with unpredictable latency, but the original bus event would be time-stamped correctly. Then you remain only with bus latencis which should be smaller than the standard deviation of your measurements. See also http://stackoverflow.com/questions/3083378/what-happens-from-the-moment-we-press-a-key-on-the-keyboard-until-it-appears-in/3083436#3083436