Pluto USB controller performance

[victhor393]

I did some testing with my Pluto running the v0.34 firmware, and I noticed that, no matter the configuration (USB host with RTL8153 network adapter, USB device with any of the network gadgets or the IIO USB backend), the USB controller seems to not be able to push more than 20-25MB/s of data to the host, or pull around 17-20MB/s from the host.

CPU usage on the Pluto seems to be reasonable, less than 50%.
That same RTL8153 adapter can do more than 40MB/s for both directions (one at a time, of course) on an Intel USB host controller (on a 480Mbps "high speed" port).

I've been wondering, is this a hardware limitation of the USB controller inside the Zynq, or could it be a driver problem?
Given the CPU usage isn't that high, this might point towards a hardware limitation of the USB IP implemented in the Zynq. I tried to do some research, but found no performance tests.

If this is not a hardware limitation, then it might be worth investigating for the extra performance.

[mhennerich]

It's a number of factors - only one is the Zynq usb controller itself.
The IIOD synchronous interface is another one, we're currently working on a async mode.
But what kills performance the most are the memory copies involved.

We're currently also investigating zero copy alternative using Linux dmabuf infrastructure.

If you maximize the IIO buffer size you should be able to achieve higher throughput.

If you switch from RNDIS to NCM mode you can get up to 32MiB/s
$ iio_readdev -n 192.168.2.1 -b 2097152 -s 200000000 cf-ad9361-lpc | pv > /dev/null
762MiB 0:00:23 [32,6MiB/s]

This is with the plain IIO usb backend:
$ iio_readdev -u usb:1.19.5 -b 2097152 -s 200000000 cf-ad9361-lpc | pv > /dev/null
762MiB 0:00:25 [29,4MiB/s]

-Michael

[victhor393]

Interesting, I think I tried ECM and RNDIS, on my tests, but maybe not NCM, good to know NCM is supposed to be faster.
This is beyond my knowledge currently, so the best I can do is test new releases... but it's good to know this is known and being worked on.

[catkira]

compiling the linux kernel with optimized settings (-mcpu=cortex-a9 -mfpu=vfpv4 -mfloat-abi=soft -O2) gave me a 10-20% improvement in sample rate I could use over ethernet. I think this is because the memory copies are potentially optimized using some SIMD instructions. But I did not check the generated asm code or do any deep analysis, because the main take away for me is to use a more powerful arm (MPSOC) if higher sample rates are needed or wait until zero copy arrives (which is probably more than a year away).