On Sun, Jul 16, 2023 at 09:31:51PM +0300, Hannu Vuolasaho wrote: > Is there a tool to show statististics of USB devices? Like how much > there is free bandwidth, which endpoints are hogging bandwidth and so > on?
I haven't seen any replies to this, so I figure I'd take a swing at sending you a few pointers I have handy. > Ideally it could be like top but for USB or a page on systat or > something like that. I do not know of such a tool (tl;dr: this is the entirety of the email, if this is all you care about, feel free to trash this email) > Are there technical reasons or am I just bad at searching? The OpenBSD USB stack is -- as I've come to discover -- delightfully spartan^Hminimalist. It supports synchronous bulk transfers via ugen, and some specific hardware via bespoke drivers, but not a heck of a lot else. Through my debugging in trying to get a userland library to place nice, I've made friends with using tcpdump(8) to capure USB traffic (see: man for tcpdump(8), look up -i, it makes mention of usb interfaces). Two notes here that may be varying degrees of helpful: 1. If you wanted to build such a tool, it may be possible to sniff traffic from the kernel by using pcap's USB support. This may give you enough information to understand the traffic on your US Bus. (saying USB Bus seems redundant don't you think?) 2. The OpenBSD USB subsystem is not what I'd call highly optimized. It gets the job done, and is generally reliable and predictable, but assumptions from other OSs break down -- especially with software designed and tested with another OS in mind. OpenBSD's USB stack has quirks, to be sure, and porting userland code that makes exotic use of the USB stack is a fucking headache. This isn't meant to criticize the OS, just to provide a bit of nuance to the actual reply, which is that performance bottlenecks may not even live where one would expect in the abstract. If I was so motiated (I haven't been so moitivated yet, to be clear :) ) and wanted to understand when I'm hitting transfer limits in USB my first approach would be to take a capture and graph the traffic, looking for flat lines (as flat lines are not generally from nature). My goal would be to understand why it's flat. The nature of the flat line may lie with the hardware, kernelspace, userland libraries or with software optmized for other operating systems. It may even be with underlying I/O writing results to (a slow?) disk or a (flaky?) network endpoint -- maybe even both? (slow i/o because of a flaky network + nfs) Sorry I can't be of help, but I wish you well. I would invite you to take a more holistic view of the system. I'd be interested if you discover anything helpful here. I haven't needed to optimize throughput, but I'm eager to understand the OpenBSD USB stack better. Take this with a grain of salt, I don't know what I'm talking about :) Fondly, paultag -- :wq