- I know plugging the 2.0 devices into a 3.0 extension won't take any advantage of 3.0 speeds. But what if they're all connected to a 3.0 hub, connected to a 3.0 cable? Would that cause those 2.0 devices to use the extra wires in a 3.0 cable, theoretically?
USB 3.0 includes the USB 2.0 connections for backwards compatibility, but the traffic is kept separate. There is a USB 2.0 controller that handles USB 2.0 traffic passing through the USB 3.0 infrastructure. So you can use USB 3.0 cables and hubs, but USB 2.0 devices get USB 2.0 treatment the entire way. The extra USB 3.0 infrastructure is ignored.
- Might forcing the event calls from all three devices through a single cable theoretically add latency?
The key word there is "theoretically". Yes, theoretically, it could add latency to combine the signals through a single path, but you would never know it if it did. Your devices (mouse, keyboard, and tablet), have very low data rates. Even compared to USB 2.0 bandwidth, the combined data from all three is like spitting in the ocean. Statistically, there will be occasions where there will be simultaneous attempts to move data, and some data will be delayed. But the delay will be in the microsecond or shorter order of magnitude. Humans can't perceive delays even in milliseconds.
That said, it wouldn't change anything because it is already happening. Groups of USB ports on your computer are connected to an internal hub (the root hub). So feeding those ports separately results in any collisions happening inside your computer. If you combine the devices on an external hub, you're just moving the location of where those collisions occur.
- I've been told that powered USB hubs act as repeaters. Is that the case, and if so, could that reduce latency? Or is that not how a repeater works?
Repeaters are used to extend the distance limits of a connection. A hub can be used as a repeater. But you can only add latency, you can't reduce it. Each time the signal is handled, there is the potential to introduce additional delay (and you can't send it back in time). But again, such delays are many orders of magnitude too short to affect anything you would be aware of.
That said, you could potentially reduce theoretical latency by using a hub (which could be a USB 2.0 hub), for a different reason. The USB 2.0 distance limit is 5 meters when using cables designed for that distance.
Say you have a device with a 5' cable and you add a 10' extension. The wire in the device cable may be sized for a total run of 5', and the wire in the extension cable may be sized for a total run of not much over 10', and the design quality of the cables may be similarly targeted to their length. In that case, each cable has already introduced the allowable losses for the connection, and you are combining the losses of the two cables.
So your setup may already be contributing latency, and it just isn't in a range that you are aware of. For this reason, the USB spec specifically defines the use of extension cables as non-compliant, although the unreliability in actual practice may be at levels acceptable for your purpose, especially with low data rate, human input devices.
Thus, combining the devices at a hub and using a long cable to connect the hub to the computer may reduce the latency of your current setup (not that you would know it), by ensuring that each connection is well within the USB limits.
Best Answer
Now in due time, I have managed to solve this myself, so I can at least follow up on it myself for posterity.
Unfortunately, I lost the original problem in a kernel upgrade, but gained a new one instead, even worse in performance, and just as hard to track down. The techniques I found were the following:
First of all,
blktrace
/blkparse
is a tool that I found quite helpful. It allows the tracing of the progress of individual I/O requests with many helpful details, such as the process that submitted the request. It is helpful to put the output ontmpfs
, so that the handling of the storage of the trace doesn't start tracing itself.That helped only so far, though, so I compiled a kernel with more debugging functionality. In particular, I found
ftrace
quite helpful, since it allowed me to trace the poorly performing process inside kernel space, to see what it did and where it blocked. Compiling a debug kernel also provides workingWCHAN
output forps
as well, which can work as an easier way to see what a process is doing inside the kernel, at least for simpler cases.I was also hoping for LatencyTop to be useful, but I found it quite buggy, and also that it only displayed latency reasons that were too "high-level" to be truly useful, unfortunately.
Also, I found it more helpful than
iostat
to simply view the contents of/sys/block/$DEVICE/stat
at very close intervals, simply like this:See
Documentation/iostats.txt
in the kernel source tree for the format of thestat
file. Viewing it at close intervals allowed me to see the exact timing and size of I/O bursts and such things.In the end, I found out that the problem I had after the kernel upgrade was caused by stable pages, a feature introduced in Linux 3.0, causing, in my case, Berkeley DB to halt for extended periods when dirtying pages in its mmap'ed region files. While it seems possible to patch this feature out, and also that the problems it causes might be fixed in Linux 3.9, I have solved the worst problem I had for now by patching Berkeley DB to allow me to put its region files in a different directory (in my case
/dev/shm
), allowing me to avoid the problem altogether.