Hi
MUX:
debian jessie
odr-dabmux 3.1.0
MOD 1:
debian jessie
odr-dabmod 2.4.1
uhd-lea-m8f-v3.14.1.0
MOD 2:
debian jessie
odr-dabmod 2.4.1
uhd-lea-m8f-003_009_00
I've configured odr-dabmux to provide ZMQ and EDI. The SFN has a 6 second time offset set in it at each MOD box. All the boxes are using ntp, and have a jitter of below 100ms.
Using ZMQ, the connection between the MUX and MOD boxes seems reliable, and I see virtually no errors.
The EDI configuration has PST enabled, FEC set for 5 blocks and interleaving over 240ms. There are three EDI destinations as unicast UDP - MOD1, MOD2 and local-loop (on three different orgination ports)
Using EDI, the stream is very unstable. I see a huge number of UHD warnings and errors about underruns and late packets:
OutputUHD status (usrp time: 1594127126.318571): 0 underruns and 1584 late packets since last status.
I also see packet sequence errors:
pseq 20442 timed out after RS
WARN EDI AF Packet sequence error, 20443
ETI FCT discontinuity, expected 192 received 193
and timestamp warnings
2020-07-07 14:15:33,946: WARN OutputSDR: Timestamp in the past at FCT=154 offset: -96.149871 (1594127733.943871) frame 154, tx_second 1594127637, pps 0.794000
2020-07-07 14:15:33,972: WARN OutputSDR: Timestamp in the past at FCT=158 offset: -96.079097 (1594127733.969097) frame 158, tx_second 1594127637, pps 0.890000
2020-07-07 14:15:33,996: WARN OutputSDR: Timestamp in the past at FCT=162 offset: -96.007393 (1594127733.993393) frame 162, tx_second 1594127637, pps 0.986000
2020-07-07 14:15:34,021: WARN OutputSDR: Timestamp in the past at FCT=166 offset: -95.936666 (1594127734.018666) frame 166, tx_second 1594127638, pps 0.082000
2020-07-07 14:15:34,047: WARN OutputSDR: Timestamp in the past at FCT=170 offset: -95.866243 (1594127734.044243) frame 170, tx_second 1594127638, pps 0.178000
2020-07-07 14:15:34,071: WARN OutputSDR: Timestamp in the past at FCT=174 offset: -95.794892 (1594127734.068892) frame 174, tx_second 1594127638, pps 0.274000
The combination of underruns, late packets, and packet sequence errors means the transmission either glitches out or causes the modulator to completely reboot.
I've looked at the incoming UDP traffic using nc -ul -p XXXX, and it's there and seems consistent. There's no obvious reason why UDP should be so dramatically less reliable than TCP.
Has anyone experience similar dramatic differences between using TCP (ZMQ) and UDP (EDI)?
Thanks
Nick