How to test Mouse Latency + Keyboard Latency – OSLTT Guide

I’ve spent months working on a new update for the latency tool – specifically OSLTT CS in terms of new features anyway – which mostly involves testing mice and keyboard latency, so I thought I’d explain what’s new, and how you actually test mice and keyboards with my tools. First, what’s new. The most obvious thing is that I’ve redesigned the UI. While I really liked having all the options right in front of you, as I add more test modes it was getting ridiculous to have to just keep making the window taller and taller as more test source options are added, plus having the trigger and sensor type split from the source wasn’t super intuitive, so now all three of the important settings are next to each other, and in handy drop-downs so I can now add more options without much hassle. I’ve also added a results folder button, so you can get access to the raw data easier. I’ve added more preset options, and clearly the space for more presets too so if you have any suggestions please do let me know – on our Discord would be best, or via email or on the Github repo. You’ve got options. Anyway, there’s also a few new things in the results viewer, namely the results settings page. This lets you see either the bar chart with all the averages/min/max when the viewer opens, or the scatter plot with the actual raw data – you can still switch between them with the button on the top of course though. You can now automatically take screenshots, both with a white background or a transparent background. You can change the text colour on the charts, which is especially helpful for those transparent screenshots if you post on a dark background, and if I open up a result here, there’s a new screenshot button. This was actually a feature request by RandomFrankP, as he does a really cool overlay of multiple results together, so this basically takes a screenshot, but removes the grid and chart axis so you just get the data. You can set the fixed Y maximum in the results settings, so all your screenshots will all line up when you layer them together.

The big new feature though is mouse move latency testing. This is all possible thanks to the peripheral testing kit on the new CS version of the latency tool, and is what we will be focusing on for the most part in this video. This new test lets you measure how long the mouse takes to start registering a movement. This isn’t the full sensor latency that RTINGS reports as that requires a servo motor and a test jig, but this is at least the initial movement latency which is a helpful measurement nonetheless. So, that’s all new features, let’s get to the guide part. I’ve already done a guide with the microphone and 2 pin input I’ll link in the cards above if you want to learn more, although I think it’s worth explaining why all three of those measurements are going to be different, even on the exact same mouse, hell even at the same time. Using the microphone as the trigger will yield you the shortest measurements. This is because the sound, either of the mouse click or the button bottoming out, is created after the switch has already electrically actuated and sent the signal. For higher than 1000 hertz mice in particular this means the mouse has generally sent the signal before the latency tool has even started counting, giving you effectively a result of 0 milliseconds. The 2 pin is the most technically accurate as that starts counting as soon as the switch is electrically actuated, although it’s the most tedious to set up, having to solder the wires to the mouse or keyboard you are testing. Then there is the tap input – the peripheral testing kit. This gives you the longest measurement as it includes the pre-travel of the switch or button, but it’s also the most realistic as you don’t experience the latency of a switch or button right from the actuation point, you have to press the damn thing first. That does mean how you test it actually has quite the effect though, hence why I’m making this guide! 

So, since testing mice and keyboards are the exact same process, just with differing switch travels, I’ll stick with mice here – although another great idea from Frank was if you are testing lots of keyboards, get a spare keycap and put the aluminium tape on it, and just swap the keycap between keyboards so you don’t have to use more tape. Anyway, for mice, the main thing is to stick the tape to the mouse button, leaving a tail for the crocodile clip to grab onto. Stick the software in mouse click testing mode, give it a description in the text box so you know what you were testing and hit start, then using the red banana plug tap the mouse button on top of the tape to both click and trigger the tool. The LED on the tool will flash when it detects a click – if it doesn’t, or if you find you get 0.002ms results, try leaving 3 seconds between results as that’s the timeout timer that should catch the tool up if it gets out of sync. Tap at a consistent rate – about once per second or so – and tap with the same force and speed each time. The harder you tap the faster the result will be, but the harder to be consistent it is. Something like this is great. 

You’ll want to do as many taps as you can for the best accuracy. I tend to do between 50 and 100 personally. Then when you are done, hit the button on the tool to end the test. 

For mouse move latency, stick the tape on the side of the mouse and change the software to the mouse move option, again give it a description, then hit start. Due to the mouse continually moving, I’ve set it up so you press a key on your keyboard to reset between taps – so hit the side of the mouse on top of the tape, then once it has stopped moving, reposition it if you want, then press any key on your keyboard (except space or the hotkey anyway). The LED on the tool will flash to show you it’s ready for the next tap, then tap again. Repeat until you are happy you’ve got enough data, then hit the button on the tool to end the test. 

As I said, keyboard testing is the exact same process as mouse click testing, although it’s worth noting that because the pre-travel distance is often considerably longer than a mouse click, the results will both be longer, and more susceptible to variance depending on how fast you tap the key. If you are testing an analogue board with an adjustable actuation point, you might want to set the actuation point to as high as you can if you want to reduce that variance as much as possible. 

That’s pretty much it, at least for using the peripheral testing kit on mice and keyboards. If you have any questions, or suggestions for new features and improvements to the tool, please do let me know in the comments, on our OSLTT channel in the Discord, email me, or drop it in an issue on the Github repo. If you’ve already got OSLTT CS, make sure to update to the most recent version of both the software and firmware to get this working, and if you don’t have one but want one, I sell kits over at OSRTT.com – that’s linked in the description if you want to check it out.