<div dir="ltr"><div>After a lot more experiments, here's an update on the multicast packet drop issue when using ka9q-radio.<br></div><div><br></div><div>The multicast RTP stream rate is about 12 Mbits/sec (192 ksps IQ one RF channel).  The client RTP</div><div>software replaces the data from a dropped packet with the (apparently) correct number of zero-value samples when</div><div>it recognizes a dropped packet. This prevents wild excursions in the client received data rate.<br></div><div><br></div><div>The Raspberry Pi 4 was replaced with a core i5-11500T running Ubuntu 22.04 (much more powerful).</div><div>This did not change the 0.1% packet loss rate issue.   However it did solve the problem of the R Pi 4 not</div><div>being able to talk very well to the client core i7 (sink) with a directly wired Ethernet connection.</div><div>The i5-11500T runs clean to the client with iperf3 both directions under all conditions tested </div><div>(no packets lost for big bursts at line rate (about 940 Mbits/sec). It should be noted</div><div>that this iperf3 test uses TCP to IPv4 LAN addresses (i.e. 192.168.x.x).<br></div><div><br></div><div>WIth a hard wired direct connection between the client and server there is no multicast packet loss.</div><div>When using either of two Ethernet switches the loss rate is ~0.1% (with statistical variation).</div><div>This is at a net data rate of 12 Mbits/sec. All the links are GbE.</div><div><br></div><div>When source and sink are on the same computer it works without packet loss (via 127.0.0.1).<br></div><div><br></div><div>Based on limited research it appears that packets in the multicast address range might be considered</div><div>exception packets by many switches. These packets are diverted from the switch's fast-path (hardware)</div><div>to the slow-path (software) for inspection in case they are IGMP packets, even if they are not.</div><div>The switches lose ~0.1% regardless of whether IGMP is enabled or disabled.  If the (relatively slow)</div><div>switch processor can't keep up, it likely discards the packet.<br></div><div><br></div><div>The switches were tested with only 2 ports UP, all the other ports physically disconnected (DOWN).</div><div>This ensures that there are no WiFi links anywhere connected, and that there is no other management</div><div>traffic traversing the switch, and IGMP doesn't have to deal with flooding congestion (since one does not flood</div><div>a DOWN link).<br></div><div><br></div><div>The source is not dropping packets according to tshark when the switch is used, but the sink is</div><div>dropping them.</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 class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 12, 2023 at 3:49 PM Tom McDermott <<a href="mailto:tom.n5eg@gmail.com" target="_blank">tom.n5eg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Phil - unfortunately there's no standard for Jumbo frame size amongst the manufacturers.</div><div>While they can go up to 16k in size, support is usually widespread for 9000 bytes, fair at 9600 bytes, and</div><div>degrades from there. They are especially helpful starting at 10 GbE.  Routers benefit the most from</div><div>Jumbo frames as it reduces the number of packets per second that have to lookup next-hop egress<br></div><div>ports, and that is mostly a software function.   <br></div><div><br></div><div>The KA9Q software right now is sending multiple lower bit rate streams and I think (without looking</div><div>through the code) doesn't benefit from the larger frames. I don't know what Phil Karm might be thinking about there,</div><div>he would be the expert to comment.</div><div><br></div><div>The Tangerine modules are on hold right now due to various issues.  The Clementine modules are intended to <br></div><div>feed into the KA9Q software.</div><div><br></div><div>-- Tom, N5EG</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 12, 2023 at 2:08 PM Phil Erickson <<a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Tom,<div><br></div><div>  That's a lot of excellent work.  Curiosity: at Haystack, we often find we have to fiddle with network switch settings to handle 'jumbo frames' (MTU > 1500) right.  This comes up as you increase the sampling rate from a particular software radio and is of course totally dependent on the wire frame protocol between the SDR and driver.  Do you expect any of the Tangerine radios to produce jumbo packets, and in any case, does the RPi4 handle that case OK without dropping things?</div><div><br></div><div>  Or perhaps you never get to this use case?</div><div><br></div><div>73</div><div>Phil W1PJE</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 12, 2023 at 3:36 PM Tom McDermott via TangerineSDR <<a href="mailto:tangerinesdr@lists.tapr.org" target="_blank">tangerinesdr@lists.tapr.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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" target="_blank">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>
-- <br>
TangerineSDR mailing list<br>
<a href="mailto:TangerineSDR@lists.tapr.org" target="_blank">TangerineSDR@lists.tapr.org</a><br>
<a href="http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org" rel="noreferrer" target="_blank">http://lists.tapr.org/mailman/listinfo/tangerinesdr_lists.tapr.org</a><br>
</blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature">----<br>Phil Erickson<br><a href="mailto:phil.erickson@gmail.com" target="_blank">phil.erickson@gmail.com</a><br></div>
</blockquote></div>
</blockquote></div>