TK1 usb3 capacity problem

In our application (camera) we need to use full speed of USB3 in TK1. Now we are not able to use full speed which we were able to get is 80fps. Please any suggestions? Or have you tried something similar and had a different result?

Thanks
Brano

Here’s a thread of possible interest. If the USB3 port has been enabled to USB3, it shows throughput is approximately on par with what USB3 should do:
https://devtalk.nvidia.com/default/topic/811034/?comment=4475113

For performance there are always lots of things which could interfere. You might want to mention what software is used, if Jetson is in CPU and GPU performance modes, if USB3 has had low power/standby disabled, so on. Here’s a couple of relevant links:
http://elinux.org/Jetson/Performance#Maximizing_CPU_performance
http://elinux.org/Jetson/Performance#Controlling_GPU_performance

I was able to run a 4MP USB3 machine vision camera (uEye) at 90fps (uncompressed 360MB/s) on TK1.

Thanks.
Are you really sure? We have tested 2 different machine vision cameras (2 different manufacturers, not IDS) and both achieved only ~50% of its speed in term of FPS. And also usb3 drive was not able copy at full speed to /dev/null.

USB3 enabled, standby disabled. Camera in freerun, short exposure.

Are there versions/revisions of TK1? We have bought it just a few days after release…

What was the speed you got when copying a file from the USB 3 drive to /dev/null? How big file was it? Did you have clocks set to maximum?

There are no different versions of Jetson TK1, afaik.

154 MB/s, 10GB file and yes - cpu & gpu had max clocks. This usb3 drive gives 240MB/s on win pc. Anyone experiencing similar max speeds?

A hard drive is just as slow under USB1.1 as it is under USB3. What speeds up is burst speed…transfer of an entire buffer at USB3 won’t show up for longer averages unless the buffer is really large and pre-filled or the buffer is being re-filled as fast as the transfer can occur. Doing so would require a very fast RAID array. The reason something like the kinect2 is a good test is because it is able to generate continuous data at full speed. The hard drive itself isn’t even remotely close to being able to generate enough data without RAID.

One possibility I have not thought about before is perhaps a device special file could be placed on the USB hard drive, like a copy of /dev/zero (mknod, major 1, minor 5, character). Then you could time bytes copied from that USB pseudo file to /dev/null on the main system and clock how fast that goes (I’m not sure how you’d measure the transfer…saving to a real file and measuring size would destroy speed). This would require the kernel to generate data at a very high rate and send it to the USB in one direction, and then pull that data back…you’d get a maximum data rate of a two-way exchange, probably between half of what one way would be capable of and the full possible speed. Kernel overhead would matter, but being a generator of only 0s overhead would be minimal. Actual data would not have any requirement on the hard drive beyond initial open.

Yes. I’m still on Linux 3.10.24-grinch-19.3.6. It was https://en.ids-imaging.com/store/ui-3370cp.html with IDS’ proprietary USB3 driver (4.30, not USB3 Vision). It was an eval and has since been returned. I haven’t tried their new USB3 vision camera. However, I decided to stick with PtGrey’s SONY CMOS IMX cameras (2.3MP) for dynamic range and noise reason. Also, I went with an 8 core Intel avoton board with 4 GigE cameras for my current project.