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
