Monitor used USB bandwidth in Win10

There are a lot of threads here about monitoring usb bandwidth, however none of them helped me, so that I post my problem here (device manager doesn't show me the usb bandwidth...):

I have a Lenovo notebook with Win10 on which I use an external USB3 camera. As long as the notebook's power cable is plugged, everything works smooth, but when removing it, the usb starts to loose data packets and frames massively. Enabling max performance in Windows power management settings hepls. However, when playing around with power settings I realized that its no usb setting (like suspend mode etc.) causing the errors, its settings of the wireless adapter. If I apply any power saving mode to the wireless adapter, my usb looses data packets. Same is true for switching off wlan, then immediately the usb looses data packets. Weird, isn't it?

My speculation is that usb controller and wifi share same recources, data bus, whatever, so that switching off wifi limits somehow usb controller bandwidth. I like therfore to monitor the current usb bandwidth. But how can I do? Is there any powershell command? Alternatively, it seems to be possible to get usb bandwidth using WinAPI, but therfore you have to dive deep into implementing Microsoft functions to your C++ source code...

Any help is welcome!


Solution 1:

After a lot of good comments to my question I was able to dive deeper into the problem and here is the conclusion: First I downloaded HWiNFO and monitored the idle states of my processors. HWiNFO offers an option to record performance, which I did for a couple of minutes while my software capturing usb camera data was running with

  1. first 3 minutes: Plugged power cable, wifi active and in no power saving mode -> no errors (no lost usb packets)
  2. next 3 minutes: Power cable unplugged, wifi active but power saving (this is default setting in windows balanced mode when running on battery) -> errors
  3. next 3 minutes: Power cable off, wifi active and set to max performance in power options -> no errors
  4. Switching wifi off (in the taskbar) -> errors

The corresponding idle states of processors and packages are displayed below:

idle states using own software

The 4 periods explained above can be clearly seen, especially in the top subplot (package idle mode). Obviously it is true and the frequency of erros (lost usb packets) is related to the time the processor spends in an idle state: The larger the percentage of time in an idle state, the more usb lost packets (or vice versa, the larger the time in C0, the less errors).

I assume my observation of loosing usb data from the attached camera when wireless adapter is switched off or saves power is just because the processor sleeps much more often when you switch off wifi or try to save power here. However, it would be helpful if some experienced user could confirm that?

However, this does explain but not solve my problem, so I continued:

I have a vendor software (basically the software which came with the camera), which is not loosing any usb data, independent of any plugged or unplugged power cables or power saving modes. This is in strong contrast to my own software I am wirting in C++ (which has the explained problems).

I repeated my test above with the vendor software. The result is not shown here, but with the vendor software the packages never go idle and thus no usb data is lost. Interesting is the following chart, where I stopped and restarted the usb camera many times in the vendor software while recording idle states with HWiNFO: Idle states while stopping and starting usb camera with vendor software

It is very clear to see that no packages ever go idle when starting the usb camera in the vendor software. When stopping it, idle states start again.

Conclusion: My original mystery is solved (idle states are the reason for lost usb packets), but the problem remains. However, it must be possible to prevent the processor (or packages) to go idle in a programmatical way, meaning I need some command that my c++ program can execute, maybe also a compiler directive to tell the processsor "don't go idle". Something like this must exist, because the vendor software seems to do that. So I am not closing the question for now but need to ask for further expert help.