Unstable clock causing MLAT problems.

[Greytech52]

Equipment: Raspberry Pi3b+ running DietPi Bookworm and ADSB Software App. Issue happens on latest V1.0.0
I think I may have found a problem with intermittent MLAT on RadarBox, I also have an MLAT error with FlightAware. "Local clock source is unstable", I had a red tick on the status page for that so looked deeper.

I have gone back to my original SD card running on a ADSBexchange image and everything is back to normal with both those aggregators so will stay on that for now. I wouldn't know where to start finding the cause of an unstable timing problem in the docker build as I am not very experienced in Linux.

Regards, Tony

[iakat]

Usually you would need an NTP client like Chrony installed.

I am not sure if that is installed via the script dietpi installation

I tried seeing what is running on my image, but I am not sure... (I am using a raspberry pi, and the raspios adsb.im image)

root@adsb-feeder:~# ps aux | grep -E 'ntp|chrony' ; find /etc | grep -E 'ntp|chrony'D
root     3555811  0.0  0.0   6016   632 pts/1    S+   12:00   0:00 grep -E ntp|chrony
/etc/apparmor.d/abstractions/apparmor_api/find_mountpoint
root@adsb-feeder:~#

(^ This is probably something for @dirkhh to look at)

[Greytech52]

There is an NTP client built into Dietpi similar to raspi, date/time was the first thing I checked. I am not sure but I think it is associated with clock jitter or drift, I have seen mention of correction factor in some sites to correct for that.

[iakat]

You are right, it is systemd-timesyncd - and it is indeed running on the image.

You can check if it is running via systemctl status systemd-timesyncd

[dirkhh]

In the default DietPi install timesync runs only once a day. You need to change it to "mode 4" where it more frequently checks the drift and adjusts

[Greytech52]

I have changed it to "Mode 4" and NTP server to my region but no change, still the identical problem as before.

[dirkhh]

Well - I don't know what to tell you. MLAT is working on several of your containers. You have a sufficiently well running NTP implementation (it's what I use on all but one of my feeders). So the only explanation that I have for the unstable clock issue would be if either CPU or memory are overloaded on your RPi3b. When under DietPi, are you running other apps? I have an RPi3a (same CPU, half the RAM) running here with both 1090 and UAT978, feeding FA and RB with no issues. However, if I add a few more aggregator, the system starts running out of memory and I see MLAT issues.

[Greytech52]

It is a fresh, clean minimal install using the latest Dietpi image. RAM usage is 542/960Mb and CPU load average is low. Not running anything else. I observed that MLAT worked correctly for about 5 minutes after a reboot then drops off on those two aggregators with unstable clock errors, I suspect this is due to clock drift but the clock is set as per your suggestion and does update on reboot. CPU is running at default speed of 1400MHz. No matter, this was an exercise to see how well it works and I have my original SD card to go back to. I appreciate your help, thank you.
Edit - I will keep it running for a few hours yet in case the clock does manage to correct its drift, when checked both those sites started working again a few minutes ago but I don't know for how long.

[Greytech52]

I think we can close this issue, it is not this program causing it. I believe that it may be due to USB data jitter and unrelated to the system time. My Pi3 is simply running out of resources, my Pi4 is working perfectly well with identical software and settings.