Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
I have two devices I want maximum throughput and latency with (MIDI drums and MIDI keyboard for example.)
Would connecting both to the same USB port via a hub effectively limit the maximum data transfer rate to 1/2 to each of them?
I am assuming yes, but I didn't know if USB hubs had a handshaking and priority giving protocol available (for example, let the device with the longer built up buffer of data communicate first).
Yes. All devices connected through a USB hub share the bandwidth available to that hub. Not specifically at 50% each though. You've got 480 Mbit/s to work with per USB 2.0 hub at the computer. What do I mean by that? Well, your computer has USB hubs built into it. Yes, not every port is an individual entity. In most cases, when you see two USB ports stacked one on top of the other, they are on a hub together internally.
This also applies with two ports side by side on laptops. So, don't think you can just plug two hubs into USB ports that are side-by-side, and have LOTS of USB ports to plug high data transfer rate devices into.
What you REALLY need to do is look at the expected data transfer rates of the devices you intend to connect. I'd expect that the MIDI drums will be considered a low transfer rate, while the keyboard will either be a low or medium transfer rate. This would be compared to something like a USB sound card... which you would not want to share a hub with anything else.
With a powered hub, each device will get the power it needs, while with an unpowered hub, all devices share whatever power the host USB port can put out. So, there is that to consider as well.
You most likely already know, but for latency issues, ASIO4ALL drivers will cure most if not all potential issues. Just putting that out there.
Actually, I'm surprised the first anwer is accepted and upvoted without any facts whatsoever to support the statement, as it's most probably a wrong one. Both MIDI drums and MIDI keyboard are almost certainly low-speed devices, so they will consume less than 1% of bandwith from a high-speed hub at most (2*1 Mbit/s / 480 Mbit/s * 100% = 0.4%).
Indeed, the presence of the hub will introduce a latency, which is of order of tens of microseconds for low-speed hubs or hundreds of nanoseconds for high-speed hubs. In the latter case, this latency will vanish once you add the latency introduced by the MIDI software.
Also, USB protocol supports transfers priorities (see Interrupt transfers), which will allow MIDI devices to coexist even with a hard drive or a scanner on the same bus without much effect on their transfer speed or latency. However, I won't make any statements since I'm not familiar with MIDI devices in particular.
The short answer is you really want a Multi-TT hub for this application, where 2 or more of your USB devices are likely 12 Mbit/sec. Search for "Multi-TT" on Amazon, Newegg or other sites to find these hubs.
Unfortunately, this important technical detail is rarely mentioned. Most hubs use a cheaper Single-TT design. The good Multiple TT ones are rarely advertised as having this feature, not even marked on the package. Sadly, most people have probably never even heard TTs, which is probably why marketers don't bother to tell you which design their hubs use.
You can check if your hub has this feature using the Windows Device Manager. Look for the words "Hub has multiple TTs" in the Advanced tab.
On Linux, the hub type can be checked with "lsusb -v | grep TT". I am not aware of any simple way to check on Macintosh, except the "USB Prober" utility which Apple publishes in their Xcode development tools.
TT stands for Transaction Translator. The details are complex, and fully documented in chapter 11 of the USB specification, which is a free download from www.usb.org. But in a nutshell, the TT converts between 480 MBit/sec from your PC to the slower 12 or 1.5 MBit/sec speeds.
Normally when you play those musical instruments, their controllers generate MIDI messages and pack then into memory buffers, which await the moment your PC requests the data. When your PC connects directly, it sends a message called an IN token to your instrument. Your instrument can respond to the IN token in two ways, either a DATA packet, or a NAK token to indicate no data. Your PC sends those IN tokens very rapidly, so the result is nearly instantaneous delivery of your musical events as MIDI messages.
However, when your 12 MBit/sec MIDI device connects through a USB 2.0 HUB, very different communication occurs, all at 480 MBit/sec. Your PC actually communicates with the Transaction Translator in the hub. It sends 2 messages. First, SSPLIT (Start Split Transaction) message is sent to the TT. If the TT is not busy, it sends an acknowledgement. Then the TT transmits the IN token to your MIDI keyboard at the slower 12 MBit/sec speed. Meanwhile, your PC is able to communicate with other devices at 480 Mbit/sec. Your MIDI keyboard can not tell if the IN token came directly from your PC or from a hub's TT. It does exactly the same thing as if connected to your PC. The TT inside the hub receives either the NAK or DATA response. While this is in progress, your PC begins sending CSPLIT (Complete Split Transaction) messages to the hub's TT. The TT replies with a special NYET token is the TT is still busy communicating at 12 Mbit/sec, or the NAK or DATA from your keyboard.
If you have both a MIDI keyboard and a MIDI drum connected, what happens if your PC wishes to send a SSPLIT message to ask the TT to communicate with the drums, but the TT is already busy communicating with the keyboard? With only a single TT, the hub may reply NYET to a new SSPLIT request, because it is busy performing the IN+DATA at 12 MBit/sec. You definitely don't want that scenario!
Multiple TT hubs have a dedicated TT on every downstream port (which you plug devices in). With multiple TTs, the hub is always able to accept a SSPLIT request, even when the other TTs are busy communicating other downstream devices. With only a single TT, your PC may end up waiting, even through there's plenty of 480 MBit/sec bandwidth, because the hub has limited ability to convert more than 1 message at a time between the different speeds.
This description glossed over many important USB timing issues the TTs handle, but the important point is USB 2.0 hubs can use two distinctly different designs. You really want to avoid the cheaper Single-TT hubs.
USB 3.0 & 3.1 speeds were mentioned elsewhere in these answers. But the TTs in hub never convert between the 5 or 10 gigabit speeds and 480, 12 or 1.5 speeds. Instead, USB 3.0 & 3.1 hubs operate as a pair of hubs. The gigabit signals have their own dedicated pins in the newer USB connectors, which connect to a hub that runs only at 5 or 10 Gbit/sec speed. Simultaneous 480 Mbit/sec communication occurs on the original pins, so 12 and 1.5 MBit/sec devices are converted to 480 Mbit/sec by TTs, but never to 5 or 10 Gbit/sec.
Also mentioned elsewhere is "low speed", which technically means 1.5 Mbit/sec in USB jargon, but may mean 1.5 or 12 Mbit/sec in casual conversation. 12 Mbit/sec is called "full speed" in USB terminology. The USB MIDI protocol, which is technically part of the "Audio Class Specification", uses "bulk" protocol (not the interrupt protocol, as claimed in another answer). The USB spec does not allow bulk transfer protocol for 1.5 Mbit/sec speed. So unless a USB MIDI device very grossly violates the USB speed, it will always be at least 12 Mbit/sec speed. USB MIDI may be 480 Mbit/sec speed, in which case the TTs don't apply. But the vast majority of USB MIDI products today are still 12 Mbit/sec speed.
So you really want to make sure your USB hubs are Multi-TT types, if you plan to maximize performance.
Realistically, sharing a single USB port by using a hub to expand how many devices you plug in is probably not going to matter too much even if you use all of the devices attached simultaneously. Most devices won't be using very much of the data transfer at a time. It's even less of a concern if you're using USB 3.0 or 3.1 ports, which are 10 and 20 times faster than 2.0, respectively, but can also send and receive data at the same time, provide more power, and will work with 2.0 devices.
As stated, so long as sufficient power is running through every device connected to the port, no problems should occur.
Just my case as an example of USB 3.0 hub slowing down when more than one device connected to it.
I have two identical sets of: SATA III to USB3.1 Gen2 Type C Enclosure with a 480`GB SSD.
If I put the SSD in a SATA III port, Linux dd command reads at more than 500 MiB/s.
If I put the SSD in the SATA III to USB 3.1 Gen2 Type C enclosure, Linux dd command reads at near than 413MiB/s, no matter which one of the two sets I use.
The weird thing comes when I plug onto the USB 3.0 both enclosures and I ask Linux to read from both (no matter if LVM stripe, RAID0 or two concurrent dd commands), it only reads at 2x150=300 MiB/s.
So when both are plugged in, I lose near 413-300=113 MiB/s of speed.
In other words:
I start to think the problem is onto the USB 3 Hub protocol to alternate data bandwidth to both drives, it adds a huge overhead.
So I can confirm the USB 3 hub I have on my hands slows down one SSD much more than max bandwidth, when more than one is connected at the same time.
Also more, I tested with one SSD and a very slow (less than 50 MiB/s) USB 3.0 stick, the USB Hub 3 combined read speed goes down to 263 MiB/s, so I can confirm combined read loose is around 100 MiB/s if I plug any other USB storage device.
And more, and also worst, I plug a mouse (or a keyboard), and SSD read speed is also near 313 MiB/s, I unplug the mouse/keyboard and SSD read speed goes back to 413 MiB/s, so again near 100 MiB/s read speed lost just because a mouse is connected (and being used); if I do not move the mouse read speed goes back to 413 MiB/s.
So the hub is causing a massive read speed drop down (near 100 MiB/s) on the combined transfer rate when not only one device is connected to it (and being used), no matter what other kind of device I connect, as soon as it has more than just one working at the same time, I get a combined read speed near 100 MiB/s lower than when using just only one device at the same time.
I had also tested with three devices: SSD + mouse + keyboard, I still loose quite near the same speed, about 100 MiB/s.
If I read from only one SSD, but have both connected, I also get near 413 MiB/s.
USB 3.0 hub price was around 20€, not a cheap one.
Conclusion: A USB hub 3.0 loses lot of MiB/s transfer speed when more than one device is connected (and transferring) at the same time, who knows why! Maybe because it divides the time transfer by the number of devices (quite wrong) or maybe because it has a huge overhead on cycling devices, etc.
Hope this helps someone identifying the problem, all tests were done under Linux Live SystemRescueCD (last version) with dd command with status=progress, block size of one megabyte and count equal to one thousand (reading a total of 1GiB), dest device /dev/null.
I am planning (when/if I am rich) on buying another USB 3.x hub, this time a 3.1 Gen 2 to check if happens the same or is that brand that has a poor firmware algorithms.
USB has gone to great lengths to give the overall impression of backwards and forwards compatibility - one connection that works with everything whether it's 1.5Mbps or 5Gbps or anything in between, but underneath in order to achieve this there is quite a bit of complexity.
There are some key things to understand about USB which will help to understand how a USB 3 compatible hub works.
All USB 3 cables and connectors (including USB-C) are effectively two wholly separate cable connections in parallel, containing both a set of wires and pins for USB 1/2 communication, and a separate set of wires and pins for USB 3 communication. Only power and ground are shared (though USB-C adds a second set of power conductors for USB-PD, not relevant here). This allows wholly independent USB 1/2 and USB 3 communication at the same time over the same cable, without regard to the other, and this is the case with all USB 3 cables and host ports.
A consequence of this is that USB 3 hubs need to contain both a USB 3 hub and a USB 2 hub, independent of each other - one operating on the USB 1/2 conductors back to the host, and the other operating on the USB 3 conductors back to the host. The USB 2 hub connects to the USB 2 conductors on all the hub's ports and the USB 3 hub connects to the USB 3 conductors on the ports.
This also helps you to understand that when a USB 3 connection is shared via a hub, any USB 3 devices connected to that hub share the combined bandwidth of the USB hub (typically 5Gbps) while any USB 1/2 devices share the maximum 480Mbps bandwidth of the USB 2 hub.
USB 1/2 is half duplex, and USB 3 is full duplex. That means that USB 1/2's bandwidth limits refer to the total of upstream + downstream, whereas USB 3's bandwidth limits refer to the total in either direction, with the possibility to have double the total bandwidth if both upstream and downstream are saturated (which is likely going to be rare).
A hub design generally downgrades the hub's overall bandwidth to the speed of the device currently communicating. That is, while a device is communicating at a low clock speed, all other devices have to wait for that slow device to finish to take their turn, effectively severely downgrading overall throughput of the hub. This would be particularly hampering for USB 1/2, where the lowest speed is a mere 1.5Mbps, much lower than both the 12Mbps and 480Mbps of USB full-speed and USB 2.0 high-speed.
So, USB 2 hubs use transaction translators whose job it is to receive data packets from low speed devices and buffer them so as not to tie up the hub, then re-transmit them onto the hub at the higher speed, and vice versa. This means that the time the transaction translator spends communicating with the low speed device isn't tying up the hub and it can be used by other higher speed devices during that time. However, hubs don't have enough transaction translators for all their ports, and many hubs have only one for the whole hub, meaning that if you have more than one low speed device you're still severely downgrading the hub throughput as only one low speed device can have their data packets buffered and transmitted over the hub at a faster speed, and any subsequent low speed communication that happens at this time will need to wait as it would have anyway. Depending on the spread of different speed devices sharing a hub, this may be more or less of a problem.
USB gives devices the ability to "reserve" a guaranteed bandwidth. Only certain devices which need a constant minimum bandwidth (like audio devices) would need this. If the request fails because the host has allocated too much reserved bandwidth the device may drop to a lower bandwidth mode or it may just fail to work. A device is supposed to release the reserved bandwidth as soon as it no longer needs it (eg, it stops streaming) but driver and device issues can cause problems with this. Reserved bandwidth can effectively limit the number of certain classes of devices that can share a bus. It can be hard to predict in what order multiple devices would request reserved bandwidth so it can be the cause of hard to diagnose devices that simply don't work sometimes on a hub. I am not aware of this existing on USB 3, but whether it does or not, this tends to only be a problem for USB 1/2 devices. Lower speed devices can be more problematic here, too - a USB 1.x low-speed device reserving only 700Kbps of bandwidth already has reserved around half of the hub's total even if transaction translation reduces actual impact on the hub, because the system has to account for the worst contention case.
While all the above pertains to bandwidth, it's worth also mentioning how latency is affected. USB hubs will naturally add latency when there is contention (multiple devices using the hub). But even in the worst of cases, the amount of latency added by a hub will be ignorable for most applications. USB 1.x low-speed and "full speed" uses 1ms long frames, which is the case with or without a hub, but if a device has to wait for some other device it can introduce a delay in multiples of 1ms. USB 2 high-speed splits that up into smaller time segments of 1/8 of a millisecond but only for USB 2 high-speed communication. USB 3 uses the same 1/8 of a millisecond for its smallest time division though with its higher data rate and full duplex operation this is going to be an issue even less often.
Knowing the above, a few tips can be used to maximise throughput.
For devices that can do USB 3 superspeed, don't worry too much about them slowing down your hub. They won't be affected by USB 1/2 devices and USB 1/2 devices won't affect them. Hubs work much better for USB 3 devices. The worst that can happen is that if you have Gen 1 (5Gbps) and Gen 2 (10Gbps) devices communicating on the same hub some of the time the hub will be downgraded to 5Gbps but there is nowhere near the problem as with the wildly different speeds of USB 1/2. A Gen 2 hub will always function at least Gen 1 speeds and sometimes Gen 2 speeds. It will never drop to a USB 1 or 2 speed.
If you have devices that use slower USB 1.x speeds (1.5Mbps or 12Mbps) but need fairly constant communication, such as external audio devices, these can tie up the USB 2 portion of your hub's bandwidth particularly if there's more than one on the hub, reducing the bandwidth available to USB 2 high speed (480Mbps) devices which could impact video capture/streaming that uses USB 2.
In fact it's probably best for any USB 1/2 device that needs fairly constant bandwidth (and where a reduction in bandwidth could be a problem) to connect directly to a host port where possible. This includes video capture, video streaming, audio interfaces, etc. Ports on a host device are usually shared on an internal hub, but internal hubs tend to have a different architecture where all ports can get the full available bandwidth.
Get USB 3 capable devices when you can, even if it's a device that doesn't really need that bandwidth, because if they use USB 3 they'll share a much bigger pool of bandwidth and not tie up the USB 2 section of your hub. Note that some devices may have USB 3 physical connectors but only actually support USB 2 - this is particularly common on simple simple devices with USB-C connectors - while USB-C physically supports USB 3 it doesn't mean devices with USB-C connectors implement USB 3, and for input devices or audio, they usually don't.
If you have multiple hubs you can use one for USB 1.x low speed devices only to separate them from the higher speed devices. And spread out your USB 3 devices across both where bandwidth won't affect USB 1/2.
Latency is almost never going to be a concern with latency being so low with USB anyway and hubs not changing that significantly.
In general connecting to ports on the host is always going to result in less contention for bandwidth - but USB hubs nonetheless offer convenience, for situations where you want to plug in more devices than the host has, or if you can't or don't want to run so many cables all the way to the host.
One of the most disappointing aspects of USB 3 is that USB 1/2 devices can still be severely limited in bandwidth when sharing a hub as their communication to the host still goes at USB 1/2 speeds. It did, however, allow USB 3 to make drastic changes to communication protocols and coding that help make its very high speeds possible.
