[Help] PS/2 Max Sample Rate - Overclock.net - An Overclocking Community

Forum Jump: 

[Help] PS/2 Max Sample Rate

 
Thread Tools
post #1 of 6 (permalink) Old 06-11-2020, 01:53 PM - Thread Starter
New to Overclock.net
 
CynthiaSakurai's Avatar
 
Join Date: Jun 2020
Posts: 1
Rep: 0
[Help] PS/2 Max Sample Rate

This may seem like a completely random or useless topic. After all, USB devices have come a long way since the PS/2 port. However, I have a weird obsession with figuring out whether or not a PS/2 port can compete currently with any USB mice. For those unaware, a PS/2 port works by sending interrupts to the CPU, telling it to completely stop what it's currently doing to process the information sent by the keyboard/mouse, while a USB connection goes to a USB Host Controller which processes the information to something that the CPU can understand, which is then sent to the CPU for processing when the CPU has time. To figure out the delays of USB and PS/2 ports I have obtained the following information, all of which has been obtained with information regarding keyboards as there is a severe lack of data for any mice data to be conclusive.



MCU + Scanning = 2.5ms delay (obtained and gathered through wooting one keyboard)

USB Host Controller = 2 nanoseconds to 2.047 milliseconds (obtained through the USB Host Controller specification sheet which is made public by Intel)



PS/2 Max Sample Rate = 200hz (5ms)

USB Max Sample Rate = 1000hz (1ms)



This isn't the end of the story though. Through some forums, I have found reports of successful overclocks to mice that resulted in upwards of 8000hz on a mouse, albeit by jumping through a lot of inevitable roadblocks. However, I have found no such reports with regards to overclocking a PS/2 port's sample rate. Taking a look at the data I currently have, a USB mouse is bound to be somewhere around a delay of 3.502ms - 5.547ms (calculated by adding delay for MCU, scanning, and polling rate) while a PS/2 connection is 7.5ms by default (calculated by adding delay for MCU, scanning, and sample rate). If a PS/2 port were to be overclocked successfully to 1000hz without any instability or issues being presented, the input delay would be reduce to 3.5ms, beating out a standard USB mouse by 0.002ms - 2.47ms assuming completely perfect scenarios.



This is where the forum post comes in. If a PS/2 port can be overclocked to say 1000hz, a PS/2 port could be definitively better than a USB port for response time. The unfortunate part is that I currently do not have a motherboard or a mouse with PS/2 ports. If anyone is interested in helping and has hardware on hand that is capable, or has past experience with doing an overclock for the sample rate of a PS/2 port, please do comment your results for a max overclock, instability you might have come across, or any other similar findings.



For those curious as to why I might consider doing this in the first place, I am currently planning to see if I can design a PS/2 mouse with optical switches to reduce input lag in competitive shooters such as CS GO or Valorant, but currently do not have the data regarding PS/2 sample rates to be able to decide whether or not there would be less input delay. If I am misinformed about the delay regarding the sample rate from a PS/2 port, please do correct me as well. I could very well misunderstand the difference between polling and sample rates, miscalculated something, not accounted for other factors, and so on.
CynthiaSakurai is offline  
Sponsored Links
Advertisement
 
post #2 of 6 (permalink) Old 06-11-2020, 05:30 PM
New to Overclock.net
 
TranquilTempest's Avatar
 
Join Date: Aug 2011
Posts: 1,785
Rep: 79 (Unique: 64)
IIRC a PS/2 report for a mouse with a scroll wheel is 32 bits, and max clock rate is 16khz. That means you have a 2ms interval if you get rid of all overhead and idle time, as opposed to the 1ms interval you can easily get with USB.

The mouse firmware itself you can get down to around 0.1ms, plus on average half the polling interval. There's not really a scanning interval when you don't have enough buttons to need a key matrix, you just give each button it's own input pin. The limiting factors would be reading the sensor, latency internal to the sensor, and the PS/2 or USB interface.

On the PC side I think your biggest problem is the game engine. With a test program you can get the USB input to display output latency to around 2ms pretty easily, but even at 500fps CS:GO will be adding another ~7ms.

TranquilTempest is offline  
post #3 of 6 (permalink) Old 06-11-2020, 08:26 PM
New to Overclock.net
 
Timecard's Avatar
 
Join Date: Dec 2015
Posts: 503
Rep: 32 (Unique: 20)
This may also be interesting to you
https://www.overclock.net/forum/373-...-2-vs-usb.html
Timecard is offline  
Sponsored Links
Advertisement
 
post #4 of 6 (permalink) Old 06-18-2020, 08:31 AM
New to Overclock.net
 
SweetLow's Avatar
 
Join Date: Jan 2016
Posts: 560
Rep: 55 (Unique: 31)
https://www.overclock.net/forum/375-...l#post25182256

and next

Q: Do you think there would be an advantage to 500 packets/s PS/2 over 500Hz USB for mice? Are there latency differences, is the data processed more consistently on PS/2 due to it not relying on processor time as much?

A: No difference at all. In the end of hardware processing both USB and PS/2 cause some kind of interrupt inside PC.
>more consistently on PS/2 due to it not relying on processor time as much
It's true that hardware principle of ps/2 and usb as "buses" is different. But from software point of view both have no difference.
Polling inside USB is _hardware_ polling, not software. The usb controller makes polls, not the CPU of PC.

>USB Max Sample Rate = 1000hz (1ms)
USB Max Sample Rate = 8000hz (as minimum of real HID devices)

Quote: Originally Posted by TranquilTempest View Post
IIRC a PS/2 report for a mouse with a scroll wheel is 32 bits, and max clock rate is 16khz.
There is 11 bit bytes So 44 bits.
SweetLow is offline  
post #5 of 6 (permalink) Old 06-26-2020, 07:32 PM
New to Overclock.net
 
Join Date: Nov 2009
Location: µcode
Posts: 822
Rep: 60 (Unique: 49)
Maybe serial (232) would be easier but would having too many updates per second swamp the software to the point of being detrimental?


Last edited by ucode; 06-26-2020 at 07:59 PM.
ucode is offline  
post #6 of 6 (permalink) Old 07-26-2020, 06:19 PM
New to Overclock.net
 
Join Date: Nov 2009
Location: µcode
Posts: 822
Rep: 60 (Unique: 49)
@CynthiaSakurai I got around to make some tests, made a little longer because of Windows double check of serial mice at boot.

Using RS232 PCIe card in NB slot with W10 1903, Haswell CPU up to 3GHz and serial mouse emulation 7-n-1 sending 4 frames (36-bits) over 1.5m cable.


At the standard 1200 Baud this gives 30ms updates, running to 460800 gives 0.08ms. As the data was streamed with no gaps it pretty much works out to 36/Baud for this case.

With idle states enabled.

One can see effect of core exit latency from CC3.

With idle states disabled


Some odd spots in above results, here's a quieter range from same results above.


Unfortunately the card I'm using seems to have problems at higher Baud approaching 1Mbps perhaps because of the nondescript transceivers but at $5 can't complain really. Would have been interesting to use the much higher rates to see what may be possible though but hope it gives you some idea.

Edit:

Best I can do for now


So speed should not be a problem rather sensor frame rate and the OS ability or lack of it to keep up, CC3 results in lost data, presumably caused by exit latency as CC0 works well also at higher speeds running in NB PCIe is a lot better than SB PCIe, maybe due to being closer to CPU.

@CynthiaSakurai there's also PCIe PS/2 cards if your interested but sadly it seems this thread may already be dead.


Last edited by ucode; 07-31-2020 at 02:28 AM.
ucode is offline  
Reply

Tags
mouse , Overclock , ps/2

Quick Reply
Message:
Options

Register Now

In order to be able to post messages on the Overclock.net - An Overclocking Community forums, you must first register.
Please enter your desired user name, your email address and other required details in the form below.
User Name:
If you do not want to register, fill this field only and the name will be used as user name for your post.
Password
Please enter a password for your user account. Note that passwords are case-sensitive.
Password:
Confirm Password:
Email Address
Please enter a valid email address for yourself.
Email Address:

Log-in



Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Show Printable Version Show Printable Version
Email this Page Email this Page


Forum Jump: 

Posting Rules  
You may post new threads
You may post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off