First of all I haven't found any other topic on this subject.
There is a bug https://lwn.net/Articles/865044/ already acknowledged since august 2021 on GPSd that will warp to 2002 all ntp stratum 1 servers that sync via gps and haven't applied the fix.
I only know that on chronyd the workaround is to apply a makestep 1 3 instead the default makestep 1 -1.
What about openwrt - what workaround can we apply on the NTP client?
21.02.0 has already gpsd 3.23 available.
As far as I understand, the problem is solved in this version.
I was reffering to NTP client mitigations - I'll also modify the title
Why do you want to solve the problem on client side, when the problem is with gpsd?
1 Like
If you are using random public servers (e.g. from pool.ntp.org), make sure your client uses at least three servers. If one of them jumps 20 years to past, it will be outvoted by the other servers. That should be the case with the default OpenWrt configuration using the busybox ntpd or chrony, which both use four servers (four pool.ntp.org servers specified in /etc/config/system or one pool specified in /etc/config/chrony using the default minsources of 4), assuming there are no bugs in the their source selection.
If two of the four servers servers fail, synchronization should stop as there will be no majority between the two failed (in the same way) servers and two good servers. Three failed servers would form a majority and cause a jump in the ntpd case, or clock running ~8.3% slower in the chrony case (which allows step only in the first three updates of the clock in its default configuration). Note that even if chrony doesn't step the local clock, its clients will still see see the jump in the served time.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.