USB polling precision - Page 2 - Overclock.net - An Overclocking Community

Forum Jump: 

USB polling precision

Reply
 
Thread Tools
post #11 of 835 (permalink) Old 04-12-2015, 02:57 PM - Thread Starter
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Quote:
Originally Posted by CorruptBE View Post

Works fine, but do it device per device or otherwise "last known safe..." might indeed not work anymore. The hardware in question has to support it.

As for power saving in the BIOS I tend to turn everything off except for C3/C6. Alot less stuttering issues, etc in some "badly" coded games. Also u can disable the Multimedia Class Scheduler service after removing the dependency from the Audio Service.

Might depend on the motherboard, for me if a component doesn't support MSI it just stays in line-based mode regardless of the entry.

Why would you disable MMCS though? It prioritizes scheduling tasks of multimedia applications over general tasks. You can tweak it to prioritize game performance and set audio to a lower priority.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms684247%28v=vs.85%29.aspx

@ uaokkkkkkkk: They're out there. What a peculiar face though... Dude should get his liver checked also.
HAGGARD is offline  
Sponsored Links
Advertisement
 
post #12 of 835 (permalink) Old 04-12-2015, 03:09 PM - Thread Starter
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Quote:
Originally Posted by aleexkrysel View Post

Good guide, I'll work through the optimization tips when I have some time in the coming days. However, I just checked my USB Controller section in Device Manager. This is what I see:
Could someone please take a noob by the hand, explain what is what and tell me how to proceed. I would be eternally grateful.
You have two EHCI in there. Those are USB 2.0 or Enhanced Host Controller Interfaces. They also provide backward compatibility for USB 1.1 devices. Root Hubs are onboard chips that handle the physical USB ports, generic Hubs are used to include additional USB ports that don't have to be directly on the board. 1 Root hub per EHCI and 1 for the 3.0 host controller (xHCI - eXtensible Host Controller Interface).
You can look at the host controller properties or view "devices by connection" to see which controller your mouse is hosted on. From there you can uncheck "PC can turn off this device to save power" in the power management tab. If you plan to disable host controllers that are not used, you can then use "show hidden devices" and uninstall the faded-out hubs associated with the now disabled controllers.
HAGGARD is offline  
post #13 of 835 (permalink) Old 04-12-2015, 04:05 PM
Linux Lobbyist
 
banjogood's Avatar
 
Join Date: Nov 2013
Posts: 189
Rep: 3 (Unique: 3)
What's up with this? http://i.imgur.com/u9xvTqk.png
banjogood is offline  
Sponsored Links
Advertisement
 
post #14 of 835 (permalink) Old 04-12-2015, 04:13 PM - Thread Starter
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
You have an outlier at the beginning there messing up your scale. Adjust Data Point Start some more.
HAGGARD is offline  
post #15 of 835 (permalink) Old 04-12-2015, 04:20 PM
Linux Lobbyist
 
banjogood's Avatar
 
Join Date: Nov 2013
Posts: 189
Rep: 3 (Unique: 3)
Quote:
Originally Posted by HAGGARD View Post

You have an outlier at the beginning there messing up your scale. Adjust Data Point Start some more.

Right. Here's my results. http://i.imgur.com/O2F4BIm.png That looks pretty terrible doesn't it?
banjogood is offline  
post #16 of 835 (permalink) Old 04-12-2015, 04:25 PM
New to Overclock.net
 
deepor's Avatar
 
Join Date: Feb 2013
Posts: 4,736
Rep: 474 (Unique: 320)
Quote:
Originally Posted by HAGGARD View Post

[...]

The active role in the polling process is occupied by the host controller. Depending on the polling interval specification, it issues timed interrupt schedules to the CPU to handle an endpoint's I/O tasks.
Interrupt service routine spawned by the host controller followed by 6 scheduled deferred procedure calls executed on core 2:

[...]

In practice, the endpoint is checked (polled) for states each Xms depending on the bInterval specification. When the mouse buffer contains data, its state is flagged accordingly to let the host know to grab that data within that same poll process. After a successful transfer the host hands the device an ACK or acknowledgement of successful transfer upon which the endpoint buffer is flushed.
The important bit here is that the host issues polls according to the set interval independent of what the mouse is doing. The USB protocol may allow for more relaxed timing schedules or interrupt priorities when the endpoint has been flagged inactive for a certain amount of time, i. e. returned no state change after a certain amount of polls, but there's no detailed information about that out there that I could find, nor is it really important here.

So, there's this set interrupt schedule spawned by the host controller that the CPU has to satisfy upon being interrupted with an ISR. Any imprecision in the polling behaviour will therefore be rooted in the CPU's inability to do so (or the controller's inability to timely prompt ISRs). Enabling the CPU to satisfy strict periodic demands is the main leverage point to get rid off polling imprecision. We achieve this by either decreasing the amount of tasks the processor has to address (DPCs that are in competition with those scheduled by the USB host, ISRs prompted by other hardware and are addressed prior to the DPCs), increasing the rate and efficiency with which the processor addresses tasks or by switching task orders and priorities around.

[...]

Are you sure you've understood that right with the host controller and the polling and the CPU? I was under the impression that the CPU doesn't work on details like that and that the host controller manages everything about the polling and getting data from the device. The host controller then triggers the interrupt after it has the data from the device to present to the CPU.

Did I misunderstand that? I tried checking the Linux kernel source code once for this, and couldn't see anything in the HID driver that deals with the polling being done. The code I looked at was just working with actual data, didn't have to do any work to get it. It was very simple and short. Is there some more work for the actual USB protocol that has to be done on the CPU? It could have maybe been hidden in some other driver so I might have made a mistake reading that code.
deepor is offline  
post #17 of 835 (permalink) Old 04-12-2015, 04:26 PM - Thread Starter
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Not terrible at all. That's roughly a second of measuring and maximum variance is 100 microseconds, average variance in the 20-50 microsecond range. It's obviously improvable, especially considering it's 500Hz which is less demanding than 1kHz, but it does mean there is no severe problem in your system.
EDIT: Just now noticed that I didn't look at your graph properly or you edited it. That's 10 microseconds at max and 2-5 microseconds average variance. doesn't get much better.

@ deepor: Not saying I know exactly which part of the polling process is handled internally on the host chip and which tasks the CPU occupies. Might even be that the CPU solely grabs data to process into messages the OS can work with.
That said, the only possible conclusion from all these settings affecting the poll precision is that the CPU ultimately is responsible for how consistently and timely mouse reports are made available for the OS and thus the cursor and applications. MouseTester looks at raw input activity at that, so it's not like the measured poll precision represents the time needed to convert mouse data into cursor movement or other events.
* Hard to find sources right now:
http://vr-zone.com/articles/blast-from-the-past-usb-polling-induced-performance-slowdowns/16620.html
http://www.baslerweb.com/media/documents/BAS1302_White_Paper_USB3+USB3_Vision-Standard_EN.pdf
In both of these you can read that USB polling is directly tied to the CPU. So the USB interrupts are more than ready data that the CPU only has to work further with from there. They are not accurately describing the process though.
HAGGARD is offline  
post #18 of 835 (permalink) Old 04-12-2015, 04:31 PM
Linux Lobbyist
 
banjogood's Avatar
 
Join Date: Nov 2013
Posts: 189
Rep: 3 (Unique: 3)
Quote:
Originally Posted by HAGGARD View Post

Not terrible at all. That's roughly a second of measuring and maximum variance is 100 microseconds, average variance in the 20-50 microsecond range. It's obviously improvable, especially considering it's 500Hz which is less demanding than 1kHz, but it does mean there is no severe problem in your system.

It's a 500Hz imo1.1. I have HPET disabled in my BIOS. I'll try playing with that. Thank you!
banjogood is offline  
post #19 of 835 (permalink) Old 04-12-2015, 05:29 PM - Thread Starter
New to Overclock.net
 
HAGGARD's Avatar
 
Join Date: Jun 2013
Posts: 657
Rep: 56 (Unique: 44)
Quote:
Originally Posted by arsn View Post

It's a 500Hz imo1.1. I have HPET disabled in my BIOS. I'll try playing with that. Thank you!
Sure thing.

Added some pictures to break some of the lengthy paragraphs.
HAGGARD is offline  
post #20 of 835 (permalink) Old 04-12-2015, 07:52 PM
New to Overclock.net
 
pinobot's Avatar
 
Join Date: Feb 2015
Location: Netherlands
Posts: 130
Rep: 5 (Unique: 4)
Maybe this is kinda relevant:

http://en.wikipedia.org/wiki/Nyquist_frequency

Ofcource with mice were not talking about sine waves.

Another example is moiré patterns when scanning books or newspapers on a flatbed scanner. You need a twice as high resolution to scan without moiré patterns.
pinobot is offline  
Reply

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