Ignore chrony source with obviously wrong time

I have a robot and am using timemaster to start chrony and add a PTP source from my GPS. When I start the robot inside where it can't get a satellite fix, the GPS claims it is January 5th, 1980. As a result, I get a stratum 0 source that is selected and the time is stepped to 1980 (because I have "makestep 1 3" configured for chrony) and then when I take the robot outside and the GPS starts advertising the correct time, it starts skewing toward 2021 which it will of course never reach. The chrony sources list looks like this for example:

[root@robot user]# chronyc sources
210 Number of sources = 5
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x PTP0                          0   2   377     4  +15173d[+15173d] +/- 8760us
^* ipv4.ntp1.rbauman.com         2   6   377    38    -43ms[  -15ms] +/-  134ms
^- 150.136.0.232                 2   7   377   148    -59ms[  -31ms] +/-  192ms
^+ 38.229.58.9                   2   8   377   216    +30ms[  +55ms] +/-  124ms
^+ ntp.speculation.org           2   7   377    38  -5919us[  +22ms] +/-  130ms

I had the time set correctly when capturing this data so you can see that first source is off by 15,173 days because 2021 - 1980 = 15000 days.

The easy and obvious fix we use is to turn everything off and then back on once we are outside but I was hoping that there is a chrony config option (or timemaster config option) that I'm missing that will ignore sources (even when they claim to be stratum 0) if it is off by oh say 20 years or some other such enormous amount of time.

I have tried changing the makestep settings but that actually makes the problem worse because if we disable makestep, someone works on the robot inside for a few hours, the clock gets skewed toward 1980 for a few hours and then the clock is wrong until it can be skewed back for an equal amount of time.

Thanks for any ideas you have. I am actually doing this on three embedded PCs running different OSes so I can't specify Linux version or chrony version. If you have a fix that only works on the latest version of chrony, I'm happy to hear it!

Solution 1:

Note that your sources output indicates PTP0 is excluded due to the enormous offset. And you have what looks like NTP Pool sources that agree within 200 ms, if they are reachable. The latter means this would be accurate if PTP0 didn't step it immediately.

Delete the makestep line and replace it with something like

initstepslew 1 2.pool.ntp.org

When chronyd starts, it will send a few packets iburst style, and step if needed. Because this is NTP only, will not be affected by the GPS fix issue.

If IP networks are often not available, like when outside, review man chrony.conf for the "infrequent connection" and "isolated networks" examples. Mark NTP servers as offline and online in networking scripts. Set up NTP servers on some computers on a local network. Any machine even with a poor real time clock would be closer than the start of the GPS epoch.

Maybe tweak the options on servers in chrony.conf to not rely only on GPS. For example:

pool 2.pool.ntp.org require

where pool.ntp.org is your configured NTP servers. require means those servers need to be not excluded for time to be adjusted. Reachable NTP servers are then required, however chrony is good at compensating for drift even when disconnected.