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).

up vote 16 down vote accepted

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.

  • +1 for ASIO4ALL. used it to kill my lag in Rocksmith. wonder doest the rocksmith community know about this! – camelbrush Nov 6 '14 at 3:28
  • Are you sure a USB audio controller will suffer a throughput bottleneck if it doesn't have an entire USB controller to itself? I think they should be designed to work on hubs, at least for 2 channel audio. – jiggunjer Feb 11 '16 at 5:15

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.

Device Manager screenshot

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: SataIII to USB3.1 Gen2 Type C Enclosure with a 480GB SSD.

If i put the SSD in a SataIII port, Linux dd command reads at more than 500MiB/s.

If i put the SSD in the SataIII to USB 3.1 Gen2 Type C enclosure, Linux dd command reads at near than 413MiB/s, no matter wich 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, i loose near 413-300=113MiB/s of speed.

In other words:

  • One SSD onto USB 3 HUB, i get 413MiB/s read
  • Two SSD onto USB 3 HUB, i get 150+150=300MiB/s read
  • Spected read (per SSD) when two SSD onto USB 3 hub would be as less as near 413/2=206MiB/s but they are only arround 150MiB/s each, not >200MiB/s as would be supposed.

I start to think the problem is onto the USB 3 Hub protocol to alternate data bandwith 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 bandwith, when more than one is connected at the same time.

Also more, i tested with one SSD and a very slow (less than 50MiB/s) USB 3.0 stick, the USB Hub 3 combined read speed goes down to 263MiB/s, so i can confirm combined read loose is arround 100MiB/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 313MiB/s, i unplug the mouse/keyboard and SSD read speed goes back to 413MiB/s, so again near 100MiB/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 413MiB/s.

So the HUB is causing a massive read speed drop down (near 100MiB/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 100MiB/s lower than when using just only one device at the smae time.

I had also tested with three devices: SSD + Mouse + Keyboard, i still loose quite near the same speed, about 100MiB/s.

If i read from only one SSD, but have both connected, i also get near 413MiB/s.

USB 3.0 Hub price was arround 20€, not a cheap one.

Conclusion: USB HUB 3.0 make a loose of lot of MiB/s transfer speed when more than one device is connected (and transfering) at the same time, who knows why! maybe because it divides the time transfer by the number of devices (quite worng) or maybe because it has a huge overhead on cycling devices, etc.

Hope this helps someone identifing 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 will be 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.

  • SSDs are very different from the devices in the question. Each SSD is trying to transfer data at more than the bandwidth of the USB 3 port. So you lose a lot of bandwidth just in collisions. – fixer1234 Sep 3 at 21:51

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.