Mlat not reaching servers?

I have been having Network problems for the last several weeks and hopefully they are fixed now.
I received this anomly message today "Anomaly report for PiAware feeder with a MAC address of b8:27:eb:18:4a:83:
31% of UDP multilateration traffic sent by piaware is not reaching the FlightAware servers. This may indicate a network problem.

I am curious, If my traffic is not getting to the servers , How do you know? Just another DUMB question!

The client keeps track of what it sent, and the server advises of what it received.

I think this issue is not from our end. I always noticed that not only one has problem with this Anomaly reports, everytime somebody post such issue other feeders has problems too . I tried everything to avoid such problem, even put a fan and make the dongle cool at all time.Dongle is pretty hot without a fan.Everytime this problem returns, i just leave and forget about it. I had my rpi scheduled to restart everytime it stop sending data to the server. I dont care if i lack data sent to them.

Shot in the dark, but it could be packet loss on your internet connection.

most internet traffic is TCP - and in that case, if a packet is dropped, it will be retransmitted. The symptom will simply be connection which is slower by direct proportion to the rate of packet loss. You may not even notice if you’re not using your connection for anything particularly bandwidth intensive.

If I remember correctly - UDP has no such mechanism by default. A UDP packet dropped has ceased to be - it is no more - unless there is another mechanism coded into the UDP client and server to detect and rerequest dropped packets.

I could be a little off on the details here - but you can confirm if my hunch is correct or wildly offbase with a tool like pingtest.net (note that this site requires a java plugin on your browser)

Yes it is UDP packet loss. There is no retransmission mechanism built into the mlat udp protocol because there’s not much benefit (the data is going to be out of date by the time the retransmission is done, and it doesn’t matter too much if some data is dropped). The loss is measured, as mduell alluded to, by the client reporting how many UDP messages it sent (the report goes over the TCP control channel) and the server comparing that number to how many messages it received.

So long as it is not a sustained problem it’s not an issue, some UDP loss is normal.

@blueskyspotter UDP packet loss has nothing to do with clock stability problems.

Are there Mlat issues today? (Friday 3-11)

Must be. None of the MLAT planes are showing positions for me either.

Thanks for the confirmation.

I spot checked the stats pages of 5 other users near me and all of their MLAT stats have tanked over the past 90 minutes. Must be server issues.