TX1 USB3 camera driver priority.


is there a way on TX1 to increase USB transfer priority above all others? I am working with a custom carrier board and a USB3 camera for 3D scanning. The camera transfers data via USB quite correctly under moderate load. However, if the CPU or network is stressed heavily, the USB starts to lose some frames and the scans are incomplete. This issue does not occur if camera is connected to PCIe directly.

Note: The USB camera should share the same bandwidth with Ethernet controller on TX1, as far as I know.

The hardware interrupts (“watch -n 1 /proc/interrupts”) are handled only on the first core. Whatever software task you can migrate to other cores will provide some relief under load. E.g., watch interrupt activity if you "sudo ping -f "…CPU0 will climb, other cores will barely change.

I can’t comment on design of any one hardware driver, but the general theme is to handle the necessary hardware steps in that driver, and then hand off to a new software interrupt for the rest of the driver details…which means you can shorten the time on CPU0 and allow non-hardware-dependent driver code to run on other cores. Badly designed drivers do all work, both hardware-dependent and hardware-independent, in a single driver without offering hardware-independent steps a chance to migrate.

If your program were to run hardware-dependent communications in one thread, and then the rest of the work in a different thread, then your own program could have core affinity set to keep the software portion on a different core, and the hardware-dependent thread on CPU0.

I don’t know of a practical way to increase priority of the USB controller within kernel space (the scheduler already does well with user space “nice” levels, and in the 4.x kernels you can use the ksoftirq to manage software interrupts…this is a change versus the 3.x kernels). You may be interested in this:

EDIT: Consider how “/proc/interrupts” shows IRQ distribution when you run this software-only command:

sudo cat /dev/urandom | strings > /dev/null

If you want to view a particular line in interrupts use “watch -n 1” with “grep”, e.g.:

watch -n 1 grep -i usb /proc/interrupts

…watch closely how some interrupt categories always show up only on CPU0.