Hello, Trying to boil down my hardware choices on a small embedded project, I decided to test USB throughput correlating with CPU usage for: FullHD Webcam, Wireless AC capable USB adapter and USB 3.0 capable FlashDrive, or HDD. As input for analysis I basically just need a I/O graph showing me how much traffic is generated at a certain point in time, no need for in depth information. Is there an option to do just that? Problem: The fancy webcam generates 100Mb+/s, causing Wireshark to completely saturate the small CPU. In the end my readings are not accurate. There are tools for HDD throughput and Wireless speed but for other USB devices like the webcam, I did not find a solution. If possible, it would also be great to do this with the same tool. TIA, Matt asked 08 Aug '16, 14:54  primergy edited 08 Aug '16, 16:55  Guy Harris ♦♦ |
One Answer:
If you run Windows on the machine and thus use USBPcap, then yes, the CPU load is enormous and I cannot exactly say why. On linux, answered 08 Aug '16, 16:36  sindy Sindy, Spot on, I was not aware of the command line option! For the record: http://desowin.org/usbpcap/tour.html Guy Harris: I have not tried other traffic in Wireshark on the weak hardware but the issue sure becomes negligible when using USBPCap via command line. It does look like a Wireshark issue. Config. example: OS: Win 10 ENT LTSB 64bit - CPU Intel N3700, 8GB memory, SSD (08 Aug '16, 17:03) primergy As my comment turned out to be useful to resolve your issue, I've made it an Answer so that you (and nobody else) could Accept it (using the checkmark icom, not the thumbs up one) so that the Question would become highlighted in green to indicate to others that a useful Answer exists. On the other hand, as your post was clearly not an Answer to your original Question, I've made it a comment. (08 Aug '16, 23:05) sindy If the resulting file also takes long to open in wireshark it might be a dissector performance thing that might be interesting to look at or profile to see if anything can be improved. If so file a bug and attach a sample file. (09 Aug '16, 11:38) Anders ♦ @Anders, see my comment to the Question. If something urgently needs profiling it is the USBPcapCMD handling of the named pipe. (09 Aug '16, 11:52) sindy An issue filed on GitHub. (12 Aug '16, 06:01) sindy |
So does the CPU max out when capturing USB traffic with Wireshark, but not when capturing other traffic with Wireshark, so that it's probably an issue with USBPcap? Or is it an issue even when not capturing USB traffic, so that it's probably a Wireshark issue?
@Guy Harris,
my laptop's hardware seems to be a bit more powerful than the one of @primergy's fanless micro board, yet it starts sweating each time I start a live capture at any of the three USB root hubs from Wireshark (i.e., using the extcap API) even if no traffic is present on that root hub. So complexity of the dissector is clearly not the source of the CPU load.
when running USBPcapCMD on much weaker hardware with embedded XP in the past, before it has been enhanced the extcap API, I haven't noticed any CPU load issues.
Hence my suggestion to the OP.
Now since there was no acoustic indicator of CPU load on that old hardware running XP, unlike my laptop where the fan noise tells you immediately that something wrong is going on, I wasn't sure whether I haven't just missed the load to exist back then. So I've made a test just now on my laptop:
running the USBPcapCMD on a silent root hub from the command line takes less than 0.05 % of CPU according to the Windows task manager,
if the capture at the same root hub is triggered from the Wireshark window, three instances of USBPcapCMD are running (any ideas why?), each taking about 28 % of CPU, while Wireshark's CPU use at that time is around 0.1 %.
So my conclusion is that the USBPcapCMD has got an issue with handling of the named queue, yet I have no idea how to use that conclusion as I've seen the last message from @desowin many months ago. I can see that the USBPcap package has been updated between 2.0.1 and 2.0.4 but I don't know whether it was by @desowin or someone else.