3 ms·
OK. Thanks for clarifying. That makes sense, sorry for being humorless! If you're looking to prove seriousness of the speed, I don't think CPU %, polling rate,
by jvanderbot 3y ago
OK. Thanks for clarifying. That makes sense, sorry for being humorless!
If you're looking to prove seriousness of the speed, I don't think CPU %, polling rate, or UDP-guesstimates are what you want. You probably want RTT measurements, which for I/O with mice via LAN is probably a little wonky to get and I guess will be dominated by network.
You could instrument your code and get latency b/w UI callback / USB poll and the time the packet hits the OS buffer / is written out (and reverse on receiver side). That's kind of the only meaningful metric that matters for I/O code and would ignore network effects, and here CPU time is a hard proxy to use.
- feschber 3y agoYeah I was planning to do some RTT measurements at some point but have not gotten round to implementing it. Would be great to have that directly in the ui as well! As you said, I was thinking to get capture->send latency and receive->emulate latency and subtracting that from the RTT to get an estimate of both network and system latency (without the compositing / presentation latency of course which is likely the largest part without some 500hz monitor).
- nikau 3y agoI used to run synergy back in the pentium III days, the trick was to change the windows service priority to real time - once that was done there was no noticeable mouse lag. I was using windows and a sun box, the windows box had to be the one with the mouse/keyboard connected so ctrl-alt-delete would work.