Marcin WicharyI would love an app that looks something like this.
I think all the data is here already,† but presented in an incomprehensible fashion.
† (Except whether a cable might be limiting the throughput, which I think would be very useful to know.)
I feel like if USB-C is such a mess where cables all look the same, having something like this to debug would help a lot.
I didn’t include power delivery, btw, which would also be helpful to know – I just don’t understand it very much.
Other nice things I could imagine:
- obviously, reacting in real time to connecting/disconnecting
- highlighting device(s) connected recently if you’re debugging
- showing activity on the cable if it’s happening
- highlighting special ports if they’re not equal
- eject buttons for devices that need it
- obviously, reacting in real time to connecting/disconnecting
- highlighting device(s) connected recently if you’re debugging
- showing activity on the cable if it’s happening
- highlighting special ports if they’re not equal
- eject buttons for devices that need it
btw thankful that even in making this mock I finally wrapped my head around this situation, as I had to make this table. I had no idea all these speeds were an option:
Gaëtan Perrault@mwichary I was about to note that we have 80gbps already, but you've discovered that.
I have an app that does something like this in Linux. Essentially a wrapper for lsusb. I forgot the name off hand, but I think it is missing a key element of your design: the throughput measurement piece.
I remember trying to look for something like this, and I ran into the problem where the drivers know the theoretical throughput, but not the actual throughout. If I'm reading screenshots correctly, you're noticing the same thing. The basic system queries don't have exactly the data we're looking for.
But I think this brings up a more subtle but complicated challenge with the original UI. One of your key requests is that you would like to identify on underperforming cable. But I don't know how the operating system can correctly differentiate between a bad cable or a bad device?... /1
@mwichary ... In the same vein, there are a few modes to each of the line weights in the diagram.
A. The theoretical maximum as displayed by the drivers.
B. The practical maximum as directly limited by the daisy chaining
C. The available maximum as implied by the active throughput of each of the devices
D. A verified maximum achieved via automatic testing
And I think this is where a UI like this kind of gets complicated.
If I plug in a 20gbps hub and then a bunch of peripherals, my actual throughput is going to be limited not just by the devices I've plugged in, but by the bandwidth they're actually using. If you plug in three monitors, a high def microphone, an external hard drive and a 2.5 gbps network cable, you could be totally fine or completely hosed based on how those things are configured and operating.
And I'm not actually sure how to do this, but I would definitely pay to have such a utility available. Answering such questions would be extremely valuable. //
@gatesvp Yeah… I know what you mean. But I think as long as we know what speed the device asked for and what speed it got negotiated down to, we could try to visualize it all.
It’s true that a device can ask for more than it needs, too.
Maybe some of this becomes a global database of devices? And in case vendor/ids lie or unreliable, you can choose the device from the dropdown.