What is the maximum achieved throughput from Tegra Tk1 USB 3.0 host controller

Hi All,

In Tegra, We are trying to interface USB 3.0 camera.

With my test results

  1. we are able to transfer image data effectively at 100MB/sec at Interactive scaling governor mode and with performance governor mode can go upto 120MB/sec. If usb throughput goes beyond that, we face image corruption in Tegra board.

We wish to know, what is the maximum through-put possible with this Tegra tk1 board without any corruption ?

Thanks and regards,
Ananth

It might be useful to know the output of “lsusb -vvv” for that camera, as well as knowing if there was any change between camera attached directly (no HUB) versus if earlier testing involved a HUB or more than one USB device connected.

Hi linuxdev,

For lsusb -vvv
https://www.dropbox.com/s/afcf9y91x4yz42k/Tegra_Tk1.txt?dl=0

The camera is directly connected to USB 3.0 port not via any hub. Other devices like mouse and keyboard are connected via otg port from board boot.

Thanks and regards,
Ananth

I don’t know if this matters, but I noticed the control interface runs at only 48MHz, while a common webcam I’m looking at uses 300MHz. I’m thinking mainly about latency here.

What I notice which will have a very high likelihood of dropping frames is the “Transfer Type” of “Bulk”. This is intended for devices such as mass storage, which sends a large chunk of data and then is interrupted and told to wait. For a streaming device such as a camera or audio, you need “Isochronous”. Isochronous transfer will provide a steady stream without the wait periods of the bulk mode. You will not achieve full performance from bulk mode except for bursts. Do you have a way to change the USB transfer type to isochronous?

FYI, a hard drive using bulk transfer has a cache and the ability to wait and block without losing data. A video or audio device should not do this for streaming, as the cache is probably insufficient (or none…implying the only way to handle pausing is to drop data), and even if cache is sufficient, there would be a noticeable jitter or complete halt.

Hi linuxdev,

Reg : control interface runs at only 48MHz
We can change it to 300Mhz. We will do it and update the result.

Reg : “Transfer Type” of “Bulk”
Currently, we are facing problems with Camera Firmware on Isochronous type. So, we stick with Bulk mode. Is there any way to reduce the wait time of processor and make the processor work virtually equivalent to Isochronous type ?

Thanks and regards,
Ananth

Hi linuxdev,

Reg : control interface runs at only 48MHz
We can change it to 300Mhz. We will do it and update the result.

Reg : “Transfer Type” of “Bulk”
Currently, we are facing problems with Camera Firmware on Isochronous type. So, we stick with Bulk mode. Is there any way to reduce the wait time of processor and make the processor work virtually equivalent to Isochronous type ?

Thanks and regards,
Ananth

Sorry, didn’t see the reply on this thread until now.

USB drivers are very standardized, I would not expect to try to modify them in the USB part of the kernel. If you want to use bulk mode you’re probably stuck making the camera itself behave more like a hard drive. You’d need to add a buffer and code to deal with control stopping and starting transfer such that buffer never completely fills. Think of the LED blinking for a hard drive doing random access. This is the intended behavior of bulk transfer mode…no loss but the endpoint device being able to buffer and stop and start in the correct data location.

If there is a process related to consumption of the USB data, you might try renicing it to a higher priority (e.g., -1), but without buffer you will still lose data, and access will still jitter.