[ntp:questions] Using ATOM with any system peer

[A C]

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 
system peer.

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.