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 ^- 184.108.40.206 2 7 377 148 -59ms( -31ms) +/- 192ms ^+ 220.127.116.11 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!