We're working off a custom board design that uses an Altera Arria10 and two AD9361s, and the kernel from the altera_4.0 branch. We ported the fmcomms5 firmware and updated the Linux device tree to accommodate. Currently our card boots, the Linux drivers probe successfully, and the iii-oscilloscope successfully connects to iiod and can communicate with both chips. Data streaming via the dma to the oscplot also works well.
We are seeing an odd performance issue when using iiod to read and write attributes and registers. When accessing attributes via libiio with the local backend on the Arria10 ARM there are no issues. For example, running 1000 debug register reads from an AD9361 takes about 0.25 seconds locally. When running the same test from a Linux PC connected via 1GigE Ethernet (using iiod’s network backend), the time to completion goes up to 40 seconds.
Digging into the code, it looks like the main loop that calls yyparse(scanner); from libiio/iiod/ops.c occasionally runs slower than normal. About 1/3 of the time it takes a long (40-60 ms) time to return, while the rest of the time the calls typically take <1 ms. The SPI reads themselves (the results of a successful command parse) always go through in <1ms once triggered, so we are suspecting either the parsing layer or something related to blocking and unblocking on the TCP socket. Wireshark confirms that the delays are in the response coming from the Arria 10 and not from the Linux PC.
No similar issue exists on the eval cards -- local and networked tests of 1000 register reads from an AD9361 on the ZC706 fmcomms5 design for example take 0.33 seconds and 1.5 seconds respectively, and the yyparse(scanner); iiod loop always returns in under 1 ms during the test.
Have you seen anything like this with libiio, or do you have any thoughts? We've run networking tests like ping floods and iperf and our 1GigE seems to be fine, so it doesn’t appear to be a networking issue.