Blur Busters Forums

BTRY B 529th FA BN wrote: ↑

01 Apr 2021, 19:04

It's also pertinent to note that AMD was having USB issues till they investigated the problem and fixed it with an AGESA update. Personally I upgraded my AMD X570/5k series chip gaming rig to a beta bios with the patch/fix and it's a huge improvement. So my experience before is not reflective of others who are not experiencing this issue, I imagine Intel gamers. I almost jumped to a new Intel system til this came along. Glad I didn't.

When was the update introduced? I got my x570 mobo back in April of last year. But I haven't had any issues though, feels better than my intel system did.

.

BTRY B 529th FA BN wrote: ↑

01 Apr 2021, 21:51

deama wrote: ↑

01 Apr 2021, 21:43

BTRY B 529th FA BN wrote: ↑

01 Apr 2021, 19:04

It's also pertinent to note that AMD was having USB issues till they investigated the problem and fixed it with an AGESA update. Personally I upgraded my AMD X570/5k series chip gaming rig to a beta bios with the patch/fix and it's a huge improvement. So my experience before is not reflective of others who are not experiencing this issue, I imagine Intel gamers. I almost jumped to a new Intel system til this came along. Glad I didn't.

When was the update introduced? I got my x570 mobo back in April of last year. But I haven't had any issues though, feels better than my intel system did.

For my Dark Hero, a week or so ago with bios 3401
My Xtreme: ... is still working on it but have released a beta, F33h, that includes the USB patch, however the rest of the bios still has bugs, but for me the mouse fix works. Like really works. Gaming has improved across the board with the games I play e.g. UT4, CS:GO. It literally is like night and day.


https://www.reddit.com/r/Amd/comments/l ... 00_series/


EDIT: in one of the links someone said "its a controller reset triggered due to to many uncorrectable pcie errors"
here: https://www.reddit.com/r/Amd/comments/m ... ttent_usb/

Ohh, 5000s series, I thought it also applied to the 3000s series too (mine).

.

So I've been reading up on the PS/2 KB & Mice Protocols and trying to figure out what you can do with what exists.

From everything that I can tell about manually OCing the Sampling Rate for the PS/2 port, that seems to only really affect the mouse side of things since the Sampling Rate really seems to only exist on the Mouse half of the protocol.

On the KB side, everything is interrupt driven and the internal clock for the PS/2 protocol is at 10-16.7 kHz. Yes that's k for kilo.

So interrupting on short strokes to start the data send is fast since it's internal clock is at 10-16.7 kHz. Far faster than anything on the USB side, with shorter latency for key strokes.

But once you have the mouse start sampling internally and sending to the Host, the Sample Rate is set as a UI08b (UnSigned Integer 8 bits) value.

What everybody seems to forget is that the limit to sampling seems to be hard coded in the protocol for the mouse side.

Every documentation I see online says that default Sampling rate is 100 Hz, but you can OC it to 200 Hz.

But I haven't seen anybody test it by OCing the Sampling rate to 250 Hz since UI08b == UI01B has a integer value range of 0-255.

I wonder how it would react to OCing the Sampling rate to 250 Hz to get that sweet sweet 4ms gap between samples?

I know it won't compete against any modern mouse that has Polling Rates up to 8 kHz.

But given modern mouse design, maximizing internal processing to fit within 4 ms sampling gaps should be a trivial task since they seem to be able to handle 8 kHz without too many issues.

But that intial Interrupt is on a internal clock that is 10-16.7 kHz. So that means initial shots fired on your mouse would be super fast and responsive. But mouse movement and any other updates would be slowed down to 250 Hz if you can get 250 Hz to work.

That should be acceptable to some players out there. Especially given how slow human latency is in pressing buttons and retriggering the interrupts.

Just some food for thought.

So I've been reading up on PS/2 KB latency and I found this little nugget to be interesting.

PS/2 KB Latency: https://archive.ph/WpAhA#selection-373.0-373.351
IBM gives the CLK inactive period as 30-50 μs, and CLK active period as 30-50 μs as well. The time to transfer one bit is then 60-100 μs. That’s a bit rate of about to 10-16.67 kHz, which at 11 bits per byte translates to about 900 to 1,500 bytes per second. In other words, it takes 660 to 1,100 μs to transfer one byte (scan code) from the keyboard.

So Input Latency range is -> (660 μs to 1.1 ms)

The absolute best/worst case would then be 660 μs; that particular clock starts counting when the host reads the keyboard data from port 60h the first time. To put it differently, after reading from port 60h once, software has at least 660 μs to read from port 60h again without worrying that a new byte might have arrived. In reality the time is likely longer because the keyboard controller is not infinitely fast and the keyboard is probably not communicating at the maximum allowed speed.

NOTE: For best performance, have minimal connections between KB/Mouse & Motherboard USB port along with dedicated individual controller processing for KB/Mouse if possible w/o sharing with other USB devices.
- The Input Latency is 16ms for USB in legacy mode when BIOS handles USB processing
- USB KB Input Latency is generally equivalent to PS/2 in worse case scenario at 1 kHz requires proper internal board & Key latency + minimal delay via OS/Drivers
- For KB Input Latency is generally equivalent to PS/2 in best case scenario at 1.6 kHz to match PS/2 best case scenario
- USB KB Input Latency is faster than PS/2 only at USB Polling Rates of 2kHz, 4 kHz, & 8 kHz, but still requires proper internal board & Key latency + minimal delay via OS/Drivers
NOTE: PS/2 will still offer the fastest initial response (Quick Draw situation), regardless of polling; but USB polling might be faster after multiple strokes in succession when set at the faster polling rates
- Even then, USB still has to wait for the polling rate to come up which could add potential latency along with internal KB Board Logic & Debounce processing to keep up with refresh rates

I got some MLT04 Mices (WMO, IME3.0, IMO1.1), which i repaired bymyself and i must say that my IME3.0 feels better than my Logitech G Pro X, when i use it via PS/2 @200hz. (I dont use it via USB cause of the struggle at overclocking in Windows 10).

I dont know how to tell why it feels better but it really does. Can be the weight/shape/sensor or some psychological effect. Ive got also the new Intellimouse Pro but it doesnt feel the same.

The only reason i dont use it for a while now is the stutter effect on FPS games (must be the 200hz limitation; on USB OCed @1000hz it wont appear). I use Odyssey G7 32'.

saprer wrote: ↑

18 Jul 2022, 14:22

I got some MLT04 Mices (WMO, IME3.0, IMO1.1), which i repaired bymyself and i must say that my IME3.0 feels better than my Logitech G Pro X, when i use it via PS/2 @200hz. (I dont use it via USB cause of the struggle at overclocking in Windows 10).

I dont know how to tell why it feels better but it really does. Can be the weight/shape/sensor or some psychological effect. Ive got also the new Intellimouse Pro but it doesnt feel the same.

The only reason i dont use it for a while now is the stutter effect on FPS games (must be the 200hz limitation; on USB OCed @1000hz it wont appear). I use Odyssey G7 32'.

Given what I know about how PS/2 mice works, if you can registry hack, try setting the Sampling Rate to 250 Hz.
The variable inside the protocol that controls the Sampling rate is a 8-bit Un-Signed Integer. So the range of values is 0-255.
If you could, try testing 250 Hz as your Sampling rate, that should push it to it's upper edge.

If that doesn't work because there is some hidden limiter else where, then so be it.

But that's what I can do for you in terms of recommendations for OverClocking your PS/2 mice to it's maximum potential.

250 Hz ain't bad, that's good for most games these days IMO.

Tried 250HZ, 210HZ and even 201hz but nothing works

saprer wrote: ↑

19 Jul 2022, 09:16

Tried 250HZ, 210HZ and even 201hz but nothing works

Then there's other checks within the Firmware/Software that enforces the 100 Hz & 200 Hz limitations.

Sadly, they weren't as cavalier about OC-ing back in the daying as we are now.