<div dir="ltr"><div>WIth awesome support from Franco, K4VZ, there has been a lot of progress in testing</div><div>KA9Q software over a wired home network.</div><div><br></div><div>The test setup uses an RTLSDR dongle to send 192 ksps IQ data from a Raspberry Pi to</div><div>an Ubuntu 22.04 core i7 host running gnuradio with Franco's gr-rtp module. This test</div><div>setup may be one where folks have available hardware available from the junkbox and</div><div>thus able to validate their system.<br></div><div><br></div><div>The FFTW wisdom file was computed on each system before starting the tests. All</div><div>connections are using 1 GbE wired connections, no WiFi links in the system. The GbE</div><div>switch is configured with IGMP snooping turned on to avoid multicasting traffic to</div><div>unsubscribed ports. IGMP was verified as working.<br></div><div><br></div><div>Initially a RPi 3B+ with GbE interface was used. At 192 ksps It had a packet drop rate of over 10 %</div><div>resulting in unusable performance. The gnuradio flowgraph was not able to demodulate</div><div>audio from the IQ stream.  It did successfully demodulate audio when the test was run</div><div>at 48 ksps, with lower packet loss rate.<br></div><div><br></div><div>Changing to a Raspberry Pi 4 at 192 ksps improved the drop rate to 0.4%.  This allowed gnuradio</div><div>to demodulate audio, but with some artifacts.</div><div><br></div><div>Last night the fft-threads=4  line was commented out of the radiod conf file, allowing</div><div>ka9q-radio to use its default of 2 threads for the fft.  This further dropped to packet loss</div><div>rate to 0.1%.  The packet losses are now infrequent (perhaps once every 15 seconds).</div><div><br></div><div>Separately all the computers and ethernet connections have been tested with iperf3.</div><div>This is a multi-platform tool (originally Unix / Linux) that sends bursts of data between the endpoints</div><div>measuring the throughput and the TCP retry rate.</div><div><br></div><div>The Ubiquiti switch does have retries, sometimes a low number, sometimes a bit larger number.</div><div>A separate small HW switch was substituted and it has zero retries with iperf3.  All the</div><div>tests show a throughput of about 940 Mbit/s regardless, so the retry rates seem pretty small.</div><div><br></div><div>The ka9q-radio packet drop rate is the same (0.1%) using either the test with the Ubiquiti switch <br></div><div>or the small HW switch, so it doesn't seem to make much difference.</div><div><br></div><div><div>The drop rate was tested with gnuradio running, and with gnuradio not running. The latter uses</div><div>pcmcat {addr/ssrc} > /dev/null to keep the IGMP path open , and the loss rate is measured with a</div><div>tshark script provided by Franco.<br></div><div><br></div><div></div>The test was repeated with ka9q-radio source and gnuradio both on a single core i7 computer</div><div>(using the loopback data connection). That system runs without drops for a few minutes</div><div>(which was the limit of the test duration).</div><div><br></div>Franco has tested RPi4 to Linux host with a direct connection without drops. However he is<div>using a different SDR receiver than RTLSDR for that test.</div><div><br></div><div>A separate test was run with a direct hard wired connection from the RPI4 to the Linux host.</div><div>One has to set static IP addresses, and inject static IP routes for the LAN and the multicast</div><div>range <a href="http://224.0.0.0/4">224.0.0.0/4</a> on both ends.   That setup was unusable with about 50% packet loss rate, </div><div>but this was prior to the fft-threads change (above). It has not been rerun since the fft-threads change.</div><div><br></div><div>Some speculations and observations:</div><div><br></div><div>* The different SDR drivers appear to have some significant performance variations.</div><div><br></div><div>* Different switches and links have different iperf3 retry rates, but they don't seem to affect the</div><div>drop rates much.</div><div><br></div><div>* The RPI3 B+seems a bit too slow for 192 ksps, but was marginally OK for 48 ksps.</div><div><br></div><div>* A faster SBC might be beneficial in place of the RPI4. That would be a good test to try.<br></div><div><br></div><div>Again, much thanks to Franco, who has provided software instrumentation to measure the loss rates</div><div>both inside of gnuradio and outside of gnuradio (i.e. with gnuradio not running).</div><div><br></div><div>-- Tom, N5EG</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div>