TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Everything about latency. Tips, testing methods, mouse lag, display lag, game engine lag, network lag, whole input lag chain, VSYNC OFF vs VSYNC ON, and more! Input Lag Articles on Blur Busters.
User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by Chief Blur Buster » 21 Oct 2020, 15:08

yah00o wrote:
20 Oct 2020, 22:43
Hey. Could you please specify how you achieved such small frequency variance in mousetest software? Any specific windows version or queryperformancefrequency value?
Most of my systems give QueryPerformanceFrequency() of less than 1 microsecond, currently I'm getting values over more than one million when I use the Windows API QueryPerformanceFrequency() which means I can measure millisecond-scale events on most of my current gaming systems.

This means it's no problem to data-analyze 8000 Hz polls if your computer is recent / configured accordingly. Whether ASUS or MSI or ASRock motherboards.

The main problem is MouseTester.exe requires you to zoom in a lot to see these. Zoom using the very bottom of the graph, and zoom repeatedly until you see the 0.125us polls spread apart. It's a bit challenging to zoom in MouseTester.exe as you have to precisely position the mouse cursor below the mouse graph line touching the bottom of the graph. Then the 2nd or 3rd zoom step is much easier.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

User avatar
MaxTendency
Posts: 59
Joined: 22 Jun 2020, 01:47

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by MaxTendency » 22 Oct 2020, 08:38

yah00o wrote:
20 Oct 2020, 22:43
Hey. Could you please specify how you achieved such small frequency variance in mousetest software? Any specific windows version or queryperformancefrequency value?
Those tests are done on windows 7 with properly optimized bios. I wrote a more detailed post on the topic if you want to check that out.
Chief Blur Buster wrote:
21 Oct 2020, 15:08
The main problem is MouseTester.exe requires you to zoom in a lot to see these. Zoom using the very bottom of the graph, and zoom repeatedly until you see the 0.125us polls spread apart. It's a bit challenging to zoom in MouseTester.exe as you have to precisely position the mouse cursor below the mouse graph line touching the bottom of the graph. Then the 2nd or 3rd zoom step is much easier.
Mouse tester (or my version atleast) always has a spike at the very beginning. This can easily be solved by putting 100 in the "Data Point Start" box.

https://streamable.com/smnjmm

My graph is a bit messy due to recording, but should give an idea. Also I personally use F2 to start and stop recording instead of holding lmb since its more convenient.

MT_
Posts: 113
Joined: 17 Jan 2017, 15:39

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by MT_ » 23 Oct 2020, 13:33

Only way to get these is indeed W7 + Full out optimization.

People think 7 polling is more stable but don't know why.

For all we know W7 somehow smoothens the result, or on W10 it is jittery by intent, for various reasons. (Still variance of 5us is doable)

Anyhow, since these tests were done on XHCI USB 3.x (I assume?) it no longer does host side polling (afaik), so I assume somehow the keyboard was pressed 1000 times a second?

Anyone care to explain?
LTSC 21H2 Post-install Script
https://github.com/Marctraider/LiveScript-LTSC-21H2

System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by Chief Blur Buster » 23 Oct 2020, 13:56

MT_ wrote:
23 Oct 2020, 13:33
(Still variance of 5us is doable)
5us variance is well below the noise floor of human visibility, fortunately. It's variances that overlap poll intervals that start to degrade 8000Hz quality closer to 4000Hz quality. Smaller variances like that such as 20us or 50us variances (0.02ms to 0.05ms) doesn't make it worthwhile to use Windows 7 instead of Windows 10 if you optimize your Windows 10 system well enough. It's currently far below all known human visibility thresholds of Vicious Cycle Effect (refresh rate race) for likely more than the next ten to twenty years, assuming jitter stays low and stable.

Besides, the Razer 8000 Hz mouse is incompatible with Windows 7 anyway (without a custom driver), but it's plug-n-play with Windows 10

As for client side polling versus host side polling, I don't currently have enough experience with those at the moment -- lack of input devices that has those options -- but it will be interesting to see potential future jitter differences with that when those arrive!
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

1000WATT
Posts: 391
Joined: 22 Jul 2018, 05:44

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by 1000WATT » 23 Oct 2020, 16:52

MaxTendency wrote:
21 Oct 2020, 00:50
  • Installing w7. Windows 7 generally has lower latency as well as superior polling compared to w10. Dual boot is usually ideal. (Go down to the misc links in the calypto guide for instructions on how to install w7 on modern mobo)
This is another myth. Results on win10 do not differ in any way. It all depends on the win assembly, components and drivers.
I do not disconnect unnecessary usb ports, I have 2 keyboards, a bluetooth adapter for a joystick, a usb microphone and a mouse. I do not disable devices in the task manager. And I don't use any optimization programs. There are no tricky settings. And I get results no worse than win7. All I have is a lite build of win10.
2.png
2.png (51.79 KiB) Viewed 12621 times
I often do not clearly state my thoughts. google translate is far from perfect. And in addition to the translator, I myself am mistaken. Do not take me seriously.

MT_
Posts: 113
Joined: 17 Jan 2017, 15:39

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by MT_ » 23 Oct 2020, 17:28

I also have never seen evidence that (Under Windows 10) you should use multiple different USB controllers to separate devices because they screw each other over.

This looks to be more like an isolated incident than anything else.

Just tried it. Even a single button hold (in a game) only induces a few ISR/DPC's at most.
LTSC 21H2 Post-install Script
https://github.com/Marctraider/LiveScript-LTSC-21H2

System: MSI Z390 MEG Ace - 2080 Super (300W mod) - 9900K 5GHz Fixed Core (De-lid) - 32GB DDR3-3733-CL18 - Xonar Essence STX II

User avatar
schizobeyondpills
Posts: 103
Joined: 06 Jun 2020, 04:00

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by schizobeyondpills » 25 Oct 2020, 15:12

Chief Blur Buster wrote:
21 Oct 2020, 15:08
Which means I can measure millisecond-scale events on most of my current gaming systems.
it only means you can be given a timestamp in milisecond scale resolution, is that timestamp accurate or precise (not the same thing) is another thing (its not).

QPC is independent of and isn't synchronized to any external time reference. To retrieve time stamps that can be synchronized to an external time reference, such as, Coordinated Universal Time (UTC) for use in high-resolution time-of-day measurements, use GetSystemTimePreciseAsFileTime.

^ is taken from https://docs.microsoft.com/en-us/window ... ime-stamps

the problem is that these are physical devices we are measuring and that requires our measuring tools to be synchronized with external real time clock reference point, impossible to do for miliseconds,microseconds or nanoseconds unless you have $100k+ equipment.

measuring without an external constantly synced time reference (in nanoseconds or lower) doesnt reveal anything because everything from cpu cycle to pixel on screen is compensated for latency/jitter/clock delay/clock desync.

unfortunate.

User avatar
Chief Blur Buster
Site Admin
Posts: 11647
Joined: 05 Dec 2013, 15:44
Location: Toronto / Hamilton, Ontario, Canada
Contact:

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by Chief Blur Buster » 26 Oct 2020, 00:28

schizobeyondpills wrote:
25 Oct 2020, 15:12
QPC is independent of and isn't synchronized to any external time reference. To retrieve time stamps that can be synchronized to an external time reference, such as, Coordinated Universal Time (UTC) for use in high-resolution time-of-day measurements, use GetSystemTimePreciseAsFileTime.
For the purposes of short-term temporals like framepacing, pollpacing, dejittering, and whatnots, we don't need reference clocks. We only need overkill precision relativity in a monotically incrementing clock with relatively small timedrift (practically zero at the required timescales we need), and that's sufficient for fixing a lot of Vicious Cycle Effect for a long time to come.

There are Right Tool for Right Job, and we definitely need precision TOD measurements. But this is not one of these situations. It isn't critical for time-relative stuff like the time differentials of frames that can be compared to adjacent framepairs (Aka framepacing statistics). TOD accuracy is generally irrelevant for that kind of statistic. And so it is also, for gametime stuff currently in the majority of current workflows. We just merely need good-enough relativity accuracy (Event timestamps, gametime timestamps, etc) down to the sub-microsecond precision. In the theoretical ultralongterm, we can also jitter-compensate polls by using continuous poll mode (a special mode so we always know it's ticktocking at 8000 polls a second, with missed-poll detection logic) and manually dejittering the polls systemside by gridlocking them to exact 0.125us separation regardless of how polls jittered from the mouse sensor to the software application. Or even future mouse input APIs that adds sensorside timestamps to the polls.

You only need microsecond counters for that (like RTDSC or QPC) and the counter can drift a bit to PC over days because both the PC and the mouse sensor microcontroller are independent clocks. But it'd be meaningless error margin over the timescales of one second. There are multiple long-term solutions to resisting internal system jitter from the perspective of gametime accuracy. Clock drift is ultra tiny in the time interval of adjacent frame pairs, to the point where it's meaningless error. Sure, some counters monotically increments inaccurately (bugs) and had tickbackwards issues (bugs), but most modern counters are sub-microsecond accurate (both in relative accuracy & drift accuracy) over the required tiny timescales of our mudane use cases of mouse poll accuracy vs gametime accuracy etc.

I am not dismissing the need for microsecond-accurate TOD for many situations. But many use cases don't need microsecond-accurate TOD -- simply that we only need microsecond-accurate time relativity over short timescales for the vast majority of fighting the Blur Busters Vicious Cycle Effect (the term I now call ever tinier things becoming problems, mudane things like higher resolutions amplifying refresh rate limitations, to things like mouse pollrate limitations showing at higher display refresh rates, etc).

In an overabundance of caution, I even now recommend game developers to cast (int) rawinput mouse positions as (double) as an intermediate math precision preserving step before the (float) of GPU APIs. It's common sense precision-preservation much like the 10-bit LUT processing step between an 8-bit GPU output and an 8-bit monitor panel. Less rounding errors build up during math processing of color processing (contrast, color, gamma mapping, etc).

Also, I got a USB3 PCI-X card. Big difference when I put my 8000Hz mouse as the only device on it, its own solid tree trunk straight to the CPU on a dedicated PCI Express lane! No bus contention, no USB contention, no second fiddle branch off a USB hub! Even CPU%-per-poll goes down slightly as it's not doing any demultiplexing sheningians anymore (whatever it is; USB sharing, interrupt sharing, or other sharing unbeknownst to our knowledge). Any weak link is now Windows/software's fault, not the USB chipset / processing / hub fault.

You are right there are many weak links but we only need to whac-a-mole sufficiently enough weak links to get sufficient worthiness out of certain hardware. We can whac the rest of the moles later, once we've whac'd enough moles for our current tick-tock of the current Vicious Cycle Effect situation.
Head of Blur Busters - BlurBusters.com | TestUFO.com | Follow @BlurBusters on Twitter

Image
Forum Rules wrote:  1. Rule #1: Be Nice. This is published forum rule #1. Even To Newbies & People You Disagree With!
  2. Please report rule violations If you see a post that violates forum rules, then report the post.
  3. ALWAYS respect indie testers here. See how indies are bootstrapping Blur Busters research!

howiec
Posts: 183
Joined: 17 Jun 2014, 15:36

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by howiec » 26 Oct 2020, 05:10

Chief Blur Buster wrote:
26 Oct 2020, 00:28
Also, I got a USB3 PCI-X card. Big difference when I put my 8000Hz mouse as the only device on it, its own solid tree trunk straight to the CPU on a dedicated PCI Express lane! No bus contention, no USB contention, no second fiddle branch off a USB hub! Even CPU%-per-poll goes down slightly as it's not doing any demultiplexing sheningians anymore (whatever it is; USB sharing, interrupt sharing, or other sharing unbeknownst to our knowledge). Any weak link is now Windows/software's fault, not the USB chipset / processing / hub fault.
May I ask which USB3 PCI-X card you're using and/or recommend (e.g. any good PCIe ones)?

rasmas
Posts: 148
Joined: 03 Jan 2018, 15:25

Re: TIP: Always put high-Hz keyboard and high-Hz mouse on SEPARATE DEDICATED USB CHIPS.

Post by rasmas » 05 Dec 2020, 09:31

By looking at this image , you can see 2 grey ports, 2 blue, and 1 red (2.0, 3.2 gen 1 and gen 2, i think). Does that means that each use a "separate dedicated USB chip", right? or still it'll be better to plug them, one on the grey and one on the red one; better than one on the red and one on the blue?

I do not have that board, is just an example as i think many have similar USBs :) .

Post Reply