Janos Konya
Member
Hi,
There may be a problem with the operation of NTP if it is not only me who is experiencing the following phenomenon:
- Planefinder's NTP log does not indicate an error, but my other two clients' MLAT streams are regularly disabled at the same time, due to a synchronization issue.
This is new, I did not experienced it in the past. It is a recurring phenomenon that "gets fixed" and then go wrong at intervals without interactions.
My physical position has not changed, my real coordinates are registered - so only the NTP offset or other parameter can cause the problem.
I have a Pi 4 based station, so I can't use the PF's own MLAT operation as a comparison base, although the NTP sync function designed for it regularly and often performs very small refinements on my raspberry box ...
NTP Status of my device:
Does PF's NTP correct the system time or just creates a "relative" time set for its own datastream?
Now I can’t think of another possible source of problems. Would you check it out?
Regards,
Janos
----------------
UPDATE:
It is possible that the above problem has been solved.
- I downgraded the pi 4 storage. I removed the recently purchased M2 SSD and put back the SD card of the original configuration. The system now seems stable.
I don’t know exactly what’s wrong when I use the SSD because apparently everything is fine. The factory power supply provides enough power and the processor is not more than 42% loaded. (even if I have 100 planes above me)
It is possible that the SSD's fast IO operations delay the processor clock even if overall the load seems normal. The small errors of the clock added up, perhaps causing a related phenomenon.
There may be a problem with the operation of NTP if it is not only me who is experiencing the following phenomenon:
- Planefinder's NTP log does not indicate an error, but my other two clients' MLAT streams are regularly disabled at the same time, due to a synchronization issue.
This is new, I did not experienced it in the past. It is a recurring phenomenon that "gets fixed" and then go wrong at intervals without interactions.
My physical position has not changed, my real coordinates are registered - so only the NTP offset or other parameter can cause the problem.
I have a Pi 4 based station, so I can't use the PF's own MLAT operation as a comparison base, although the NTP sync function designed for it regularly and often performs very small refinements on my raspberry box ...
NTP Status of my device:
Does PF's NTP correct the system time or just creates a "relative" time set for its own datastream?
Now I can’t think of another possible source of problems. Would you check it out?
Regards,
Janos
----------------
UPDATE:
It is possible that the above problem has been solved.
- I downgraded the pi 4 storage. I removed the recently purchased M2 SSD and put back the SD card of the original configuration. The system now seems stable.
I don’t know exactly what’s wrong when I use the SSD because apparently everything is fine. The factory power supply provides enough power and the processor is not more than 42% loaded. (even if I have 100 planes above me)
It is possible that the SSD's fast IO operations delay the processor clock even if overall the load seems normal. The small errors of the clock added up, perhaps causing a related phenomenon.
Last edited:
