[ntp:questions] Using ATOM with any system peer
agcarver+ntp at acarver.net
Mon Mar 26 20:01:44 UTC 2012
Would it be possible to modify the ATOM driver such that it will be
activated when a system peer is selected and avoid the need to use a
"prefer"ed server? As has been mentioned in the past the prefer keyword
disrupts the clock selection algorithm. I want ntpd to continue using
clock selection but still have the ATOM working when something is a
The reason I ask is I've discovered an interesting race condition last
night. As an experiment I tried setting everything to prefer so that
there would be some kind of selection process occurring. Granted it's
just in order of the clocks but that's better than one prefer and
nothing else ever being selected. If there is a glitch that drops the
other clocks, it picks one clock and tries to synchronize again.
Unforunately (and noted in another email I just sent) the SHM refclock
is selected first even though it is last in the configuration file. Now
the race begins. The SHM is fed from the GPS receiver, so the offset
wanders around a bit. But because it's marked as one of several
preferred peers, it gets selected anyway (even though it shouldn't by
the multiple prefer rules). The wandering clock isn't stable enough to
tame the system clock which, for the past four hours, has been
performing clock steps of several tenths of seconds every few minutes.
It never fully stabilizes and ntpd ends up resetting everything and
starting over after each clock step. I have to kill and restart the
process to allow the iburst process to tame the clock.
If I could avoid the prefer entirely, then ntpd would settle on any
server available, clean up the clock and then activate ATOM to control
the ticking. If a glitch occurs, the clocks are chosen again in the
normal process and then ATOM is reactivated.
The serial port drivers aren't going to be fixed anytime soon to support
double-opens required to use something like NMEA with PPS so I'd just
like to relax the requirement that a peer be marked as preferred for
ATOM to work and just accept any system peer that the clock selection
algorithm chooses as the current peer. If everything is working like it
should, then it shouldn't matter if the peer hops around because ATOM
controls the ticks and the peers won't be far off from each other to
number the seconds.
More information about the questions