Does a USB hub affect performance?
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).
usb performance midi usb-2
add a comment |
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).
usb performance midi usb-2
add a comment |
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).
usb performance midi usb-2
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).
usb performance midi usb-2
usb performance midi usb-2
edited Aug 6 '15 at 21:24
Peter Mortensen
8,361166185
8,361166185
asked Jun 15 '12 at 20:22
SwimBikeRunSwimBikeRun
3311720
3311720
add a comment |
add a comment |
6 Answers
6
active
oldest
votes
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
add a comment |
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 '18 at 21:51
add a comment |
When I use a direct connection between my laptop computer, which has a 750GB 5400rpm hard drive, and my 8GB external hard drives, the transfer rates are actually much slower than when I use a USB hub. For example, I recently copied and pasted four movies adding up to about 120GB of data. Here is what happened.
First, I copied the four movies adding up to 120GB of data on my laptop hard drive, and then pasted them onto the one 8GB external hard drive. It took about 80 minutes to transfer, because the data transfer rate was only about 30mbs. The data transfer rate had spikes that ranged from 20mbs to 35mbs.
Second, I then connected the other 8GB external hard drive that is the exact same model. This time I used the 4-port USB 3.0 hub. This time the data transfer rate was much faster - at times over 90mbs. The data transfer rate had spikes ranging between 50mbs to over 90mbs. It took only 30 minutes to transfer the data.
Third, as an experiment, I connected both of the 8GB external hard drives at the same time via the USB 3.0 hub. I copied all four movies with the 120GB of data from one hard drive to the other. This time the transfer was even faster than ever. The data transfer rate was about 150mbs, and there were no spikes at all in the transfer rate. It was a steady line of 150mbs the entire time.
I have done experiments with other large data transfers. For some reason, the direct USB 3.0 connection to an external hard drive is much slower than when a USB 3.0 hub is involved. ... Does anyone know why this is?
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f437429%2fdoes-a-usb-hub-affect-performance%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
6 Answers
6
active
oldest
votes
6 Answers
6
active
oldest
votes
active
oldest
votes
active
oldest
votes
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
add a comment |
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
add a comment |
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.
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.
edited Aug 6 '15 at 21:26
Peter Mortensen
8,361166185
8,361166185
answered Jun 16 '12 at 3:11
Bon GartBon Gart
12.5k11834
12.5k11834
+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
add a comment |
+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
+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
+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
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
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Aug 6 '15 at 21:30
Peter Mortensen
8,361166185
8,361166185
answered May 22 '15 at 13:43
Dmitry GrigoryevDmitry Grigoryev
5,83612057
5,83612057
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Feb 28 '17 at 5:30
Journeyman Geek♦
112k43217369
112k43217369
answered Feb 14 '17 at 9:48
Paul StoffregenPaul Stoffregen
12113
12113
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited May 22 '15 at 11:48
nerdwaller
12.1k12939
12.1k12939
answered May 22 '15 at 11:35
XiroXiro
311
311
add a comment |
add a comment |
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 '18 at 21:51
add a comment |
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 '18 at 21:51
add a comment |
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.
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.
edited Sep 3 '18 at 12:03
answered Sep 3 '18 at 11:55
LauraLaura
11
11
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 '18 at 21:51
add a comment |
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 '18 at 21:51
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 '18 at 21:51
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 '18 at 21:51
add a comment |
When I use a direct connection between my laptop computer, which has a 750GB 5400rpm hard drive, and my 8GB external hard drives, the transfer rates are actually much slower than when I use a USB hub. For example, I recently copied and pasted four movies adding up to about 120GB of data. Here is what happened.
First, I copied the four movies adding up to 120GB of data on my laptop hard drive, and then pasted them onto the one 8GB external hard drive. It took about 80 minutes to transfer, because the data transfer rate was only about 30mbs. The data transfer rate had spikes that ranged from 20mbs to 35mbs.
Second, I then connected the other 8GB external hard drive that is the exact same model. This time I used the 4-port USB 3.0 hub. This time the data transfer rate was much faster - at times over 90mbs. The data transfer rate had spikes ranging between 50mbs to over 90mbs. It took only 30 minutes to transfer the data.
Third, as an experiment, I connected both of the 8GB external hard drives at the same time via the USB 3.0 hub. I copied all four movies with the 120GB of data from one hard drive to the other. This time the transfer was even faster than ever. The data transfer rate was about 150mbs, and there were no spikes at all in the transfer rate. It was a steady line of 150mbs the entire time.
I have done experiments with other large data transfers. For some reason, the direct USB 3.0 connection to an external hard drive is much slower than when a USB 3.0 hub is involved. ... Does anyone know why this is?
add a comment |
When I use a direct connection between my laptop computer, which has a 750GB 5400rpm hard drive, and my 8GB external hard drives, the transfer rates are actually much slower than when I use a USB hub. For example, I recently copied and pasted four movies adding up to about 120GB of data. Here is what happened.
First, I copied the four movies adding up to 120GB of data on my laptop hard drive, and then pasted them onto the one 8GB external hard drive. It took about 80 minutes to transfer, because the data transfer rate was only about 30mbs. The data transfer rate had spikes that ranged from 20mbs to 35mbs.
Second, I then connected the other 8GB external hard drive that is the exact same model. This time I used the 4-port USB 3.0 hub. This time the data transfer rate was much faster - at times over 90mbs. The data transfer rate had spikes ranging between 50mbs to over 90mbs. It took only 30 minutes to transfer the data.
Third, as an experiment, I connected both of the 8GB external hard drives at the same time via the USB 3.0 hub. I copied all four movies with the 120GB of data from one hard drive to the other. This time the transfer was even faster than ever. The data transfer rate was about 150mbs, and there were no spikes at all in the transfer rate. It was a steady line of 150mbs the entire time.
I have done experiments with other large data transfers. For some reason, the direct USB 3.0 connection to an external hard drive is much slower than when a USB 3.0 hub is involved. ... Does anyone know why this is?
add a comment |
When I use a direct connection between my laptop computer, which has a 750GB 5400rpm hard drive, and my 8GB external hard drives, the transfer rates are actually much slower than when I use a USB hub. For example, I recently copied and pasted four movies adding up to about 120GB of data. Here is what happened.
First, I copied the four movies adding up to 120GB of data on my laptop hard drive, and then pasted them onto the one 8GB external hard drive. It took about 80 minutes to transfer, because the data transfer rate was only about 30mbs. The data transfer rate had spikes that ranged from 20mbs to 35mbs.
Second, I then connected the other 8GB external hard drive that is the exact same model. This time I used the 4-port USB 3.0 hub. This time the data transfer rate was much faster - at times over 90mbs. The data transfer rate had spikes ranging between 50mbs to over 90mbs. It took only 30 minutes to transfer the data.
Third, as an experiment, I connected both of the 8GB external hard drives at the same time via the USB 3.0 hub. I copied all four movies with the 120GB of data from one hard drive to the other. This time the transfer was even faster than ever. The data transfer rate was about 150mbs, and there were no spikes at all in the transfer rate. It was a steady line of 150mbs the entire time.
I have done experiments with other large data transfers. For some reason, the direct USB 3.0 connection to an external hard drive is much slower than when a USB 3.0 hub is involved. ... Does anyone know why this is?
When I use a direct connection between my laptop computer, which has a 750GB 5400rpm hard drive, and my 8GB external hard drives, the transfer rates are actually much slower than when I use a USB hub. For example, I recently copied and pasted four movies adding up to about 120GB of data. Here is what happened.
First, I copied the four movies adding up to 120GB of data on my laptop hard drive, and then pasted them onto the one 8GB external hard drive. It took about 80 minutes to transfer, because the data transfer rate was only about 30mbs. The data transfer rate had spikes that ranged from 20mbs to 35mbs.
Second, I then connected the other 8GB external hard drive that is the exact same model. This time I used the 4-port USB 3.0 hub. This time the data transfer rate was much faster - at times over 90mbs. The data transfer rate had spikes ranging between 50mbs to over 90mbs. It took only 30 minutes to transfer the data.
Third, as an experiment, I connected both of the 8GB external hard drives at the same time via the USB 3.0 hub. I copied all four movies with the 120GB of data from one hard drive to the other. This time the transfer was even faster than ever. The data transfer rate was about 150mbs, and there were no spikes at all in the transfer rate. It was a steady line of 150mbs the entire time.
I have done experiments with other large data transfers. For some reason, the direct USB 3.0 connection to an external hard drive is much slower than when a USB 3.0 hub is involved. ... Does anyone know why this is?
answered Jan 5 at 22:14
mike_mgobluemike_mgoblue
1
1
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f437429%2fdoes-a-usb-hub-affect-performance%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown