We use the TypeC interface of the Orin nano Developer kit to connect to the USB 3.0 port on the PC. At this time, the Orin nano is in device mode. Then we use the mass_storage example for file transfer testing, and the conclusion we obtained is that the file transfer speed is only 38MB/s
head -1 /etc/nv_tegra_release: # R35 (release), REVISION: 3.1, GCID: 32827747, BOARD: t186ref, EABI: aarch64, DATE: Sun Mar 19 15:19:21 UTC 2023
kernel log:
[ 181.817516] tegra-xudc 3550000.xudc: EP 5 (type: intr, dir: in) enabled
[ 181.817538] tegra-xudc 3550000.xudc: EP 3 (type: bulk, dir: in) enabled
[ 181.817553] tegra-xudc 3550000.xudc: EP 2 (type: bulk, dir: out) enabled
[ 181.817639] tegra-xudc 3550000.xudc: EP 9 (type: intr, dir: in) enabled
[ 181.817656] tegra-xudc 3550000.xudc: EP 7 (type: bulk, dir: in) enabled
[ 181.817669] tegra-xudc 3550000.xudc: EP 4 (type: bulk, dir: out) enabled
[ 181.817703] tegra-xudc 3550000.xudc: EP 15 (type: intr, dir: in) enabled
[ 181.817729] tegra-xudc 3550000.xudc: EP 11 (type: bulk, dir: in) enabled
[ 181.817754] tegra-xudc 3550000.xudc: EP 6 (type: bulk, dir: out) enabled
[ 181.817847] IPv6: ADDRCONF(NETDEV_CHANGE): rndis0: link becomes ready
[ 910.895185] nvgpu: 17000000.ga10b fbp_pg_mask_store:971 [INFO] no value change, same mask already set
[ 910.895203] nvgpu: 17000000.ga10b tpc_pg_mask_store:1067 [INFO] no value change, same mask already set
[ 917.528493] nvgpu: 17000000.ga10b railgate_enable_store:323 [INFO] railgate is disabled.
[ 1142.060167] usb 2-1.3: reset SuperSpeed Gen 1 USB device number 3 using tegra-xusb
[ 1313.217164] usb 2-1.3: reset SuperSpeed Gen 1 USB device number 3 using tegra-xusb
How should I modify my device to achieve a speed of 5Gbps for Type-C?
1、Firstly, create a new “filesystem.img” file to replace the same-named file in “/opt/nvidia/l4t-usb-device-mode”. This will allow us to obtain a larger file for testing on the PC side.
cd /opt/nvidia/l4t-usb-device-mode
mv filesystem.img filesystem.img_bak
dd if=/dev/zero of=filesystem.img bs=1M count=1000
mkfs -t fat ./filesystem.img
mkdir data
mount -o loop filesystem.img ./data
cd data
dd if=/dev/zero of=file.img bs=1M count=900
cd ..
umount data
2、unplug and replug the Type-C cable. A new storage device should appear on the PC, containing a new file named “file.img”.
3、Copy “file.img” to your PC and test its transfer speed.
I doubt that is a valid test unless you also format the loopback device as ext4. Loopback is trying to make that look like a block device, and the layer over it wants to find ext4 (or some format). There is a lot going on other than just the USB speed.
Instead of naming a fake partition, you could just name the rootfs on “/” while testing (I’d never suggest that as something you ship enabled, but for testing it is a good idea). No loopback, and a legitimate ext4. Even this though depends on the speed of the SD card or eMMC (depending on model).
Consider this test: Get an external USB3 hard drive. Something fast, e.g., SSD. Make sure it is in USB3 mode. Then copy (without loopback) the file you created, “filesystem.img”, to the external drive. Time it or otherwise benchmark it. It is likely the source device (especially if it is an SD card) is far slower than USB3.1 gen. 1 or gen. 2.
Also, reading a filesystem tends to add buffer via unused RAM. The first read would be the slowest, and it would probably speed up for the second read if memory pressure has not altered the buffer.
I probably won’t be able to reply very quickly over the next week, and there is a reasonably high chance that device mode USB is low performance, but I also think your test isn’t very good since it has too many things in between via loopback.
My goal is to test the communication speed between Orin Nano (device mode) and an x86 PC, so using an external storage device for testing as you suggested is not what I want.
Actually, I developed a device mode driver myself and tested it on an x86 PC using the libusb library, but I also got unsatisfactory results, 40MB/s.
my device mode driver is base on f_loopback.c . This is the source code：
Communication speed is probably bottlenecked by reading files as the data. Maybe read “/dev/null”?
An interesting network service, which is by default disabled, is the “echo” port. Take a look at “/etc/services”. Port 7 has both a UDP and a TCP version (not valid if the service is not enabled). If this is enabled, then any text you send via either TCP or UDP is sent back. If you send a file’s text content which is 1 MB in size, then 2 MB of traffic occurs, and the time is an average for both send and receive without the disk ever getting involved. That would be a true test of networking without disk interference.
I’m not where I can look up how to enable the echo port right now.
What I need to test is the performance of USB3.0, not the performance of the network. I have already tested the network performance, which can achieve 110MB/s for network file transfer. But now I need to know the performance of USB3.0 under device mode. Do you know how to test USB3.0 in device mode?
Perhaps you could use dd to read a disk, and push the data to “/dev/null”. That’d be read speed at least. For write speed, you could read “/dev/zero”, and write to the disk, but both would depend on the max speed of the disk. However, if you read at least twice from the disk, then it would perhaps be cached. Device mode would be the same, but you’d consider the Jetson the device, and you’d make those tests with a desktop PC.
The key to piping and testing is probably the pv command. Check this illustration: dd bs=1M if=/dev/zero count=100 | pv -p -r -a > /dev/null
(this transfers blocks of 1MB, all data being NULL bytes, 100 times, to “/dev/null”, and measures performance)
One can easily substitute a large file for a source or destination, using cat. dd is nice for control though.
