> > I think xntpd needs the clock to be within 500 ppm or the PLL won't 
> > lock up.

> Is that actually documented anywhere?

I didn't find any clean statement in the html or man page.

It seemed pretty well known in the ntp community.  A couple of months 
ago I was trying to track down a Linux clock bug on these machines.  
One of the first responses I got back pointed out that limit.  (That 
may be only for the new ntpd vs older xntpd.) 


grepping for ppm and 500 in the xntpd sources found this comment 
in ntp_loopfilter.c. 

         * If the magnitude of the offset is greater than CLOCK_MAX (128
         * ms), reset the poll interval and wait for further
         * instructions. Note that the cutout switch is set when the
         * time is stepped, possibly because the frequency error is off
         * planet. In that case all sanity checks are disabled and the
         * discipine loop is on its own. Presumably, the loop will
         * eventually capture the wayward oscillator (if less than 500
         * ppm off planet) and converge, which will then reset the
         * cutout switch.


I admit to being somewhat suspicious about my claim given that other 
branches have large errors.  I assume there would be a few time geeks 
running NetBSD who would would have complained if things didn't work 
right.