Looking for ntp/PPS setup guide

[Eric Brown]

On Sat, Jul 31, 2004 at 04:19:08PM -0700, Kevin Oberman wrote:
> > Date: Sat, 31 Jul 2004 14:46:27 -0600 (MDT)
> > From: "M. Warner Losh" <imp at bsdimp.com>
> > 
> > In message: <20040730000205.E834A5D09 at ptavv.es.net>
> >             "Kevin Oberman" <oberman at es.net> writes:
> > : > From: Gregory Bond <gnb at itga.com.au>
> > : > Date: Fri, 30 Jul 2004 09:38:32 +1000
> > : > Sender: owner-freebsd-stable at freebsd.org
> > : > 
> > : > 
> > : > We've got a GPS receiver to make an NTP server, and it has PPS output.
> > : > Is there a guide to how to set up PPS on recent (4.10-ish) FreeBSD
> > : > boxes?  Or I can put it on a 5.x box if that is better. I've had a
> > : > look in all the obvious places but the only references I can find are
> > : > to old (load a line discipline or patch a kernel) solutions.
> > : 
> > : I'd suggest the documentation at www.ntp.org, but it has a few errors
> > : and lacks a bit of FreeBSD specific bits.
> > : 
> > : First off, you will need to rebuild ntpd with the appropriate reference
> > : clocks, pps and whatever type of GPS you have. The software is in
> > : /usr/src/contrib/ntp/ntpd. You can look at the list of clock drivers and
> > : pick the one you need. If you look at the driver source, you will see
> > : that REFCLOCK and a driver specific variable need to be defined.
> > : 
> > : Go to /usr/src/usr.sbin/ntp/ntpd and rebuild ntpd with the clock driver:
> > : make clean
> > : make -DREFCLOCK -DCLOCK_yourclock
> > : make install
> > : 
> > : You need to rebuild you kernel with "options PPS_SYNC". You can run PPS
> > : without this and the man page even says it's more accurate that way, but
> > : my experience is that it is much more accurate with the kernel option.
> > : I use CDMA clocks and they my time is stable within 10 microseconds.
> > 
> > I've found that w/o PPS_SYNC, we get worse results than when we have
> > it enabled.Of course, most of my work with this is with a pps that is
> > from a HP5071A atomic clock :-)
> 
> Show off! 
> 
> >From what I have seen, the non-kernel PPS software handles jitter more
> gracefully than the kernel version. My CDMA clock has about 4
> microseconds of jitter with a spec of <10 and I suspect that your
> HP5071A is a bit better in that regard. Since the PPS_SYNC stuff seem to
> work very well as long as there is no significant jitter in the source,
> I'll agree that it's the way to go for something as accurate as your
> clock. Whether it turns out to be a win for mine depends on long-term
> data that I should have Monday. (I moved my test system from PPS_SYNC to
> PLL sync yesterday.
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> +TRUETIME(1)     .CDMA.           0 l    6   16  377    0.000    2.699   5.184
> oPPS(1)          .PPS.            0 l   16   16  377    0.000    0.001   0.004
> +bnl-owamp.es.ne .PPS.            1 u    7   64  377   71.908    0.051   0.034
> 
> It is critical that maxpoll and minpoll be set to 4 if the kernel
> PPS_SYNC is not used. When I failed to do that, I got very poor
> long-term stability.
> 
> I am also unsure how NTP calculates error estimates when PPS is used. The
> values I see are not believable. Way too big. They look more like the
> error estimates for TrueTime clock that PPS disciplines.
> 
> > : I did find that nptd 4.2 seemed to converge better than 4.1, so I built
> > : the ntp port instead of the standard one. I then just installed the ntpd
> > : from the port over the one in /usr/sbin. 4.2 is now the standard NTP in
> > : version 5 and I suspect it will be MFCed to STABLE soon.
> > : 
> > : Read the manual pages for pps and your GPS clock driver for how to set
> > : up ntp.conf for that clock. You will need to set up kernel PPS there.
> > 
> > This can be the hardest part.  The documentation is a little less than
> > stellar. :-(
> 
> The twiki can help and I really hope to put in some good FreeBSD
> specific stuff into it when time permits, but I'll agree that the
> documentation can be confusing, hard to follow, and sometimes simply
> wrong.  But some of my own documentation is at least confusing and hard
> to follow, too. ;-)
> -- 
> R. Kevin Oberman, Network Engineer
> Energy Sciences Network (ESnet)
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
> E-mail: oberman at es.net			Phone: +1 510 486-8634

I'm running PPS from a DATUM GPS receiver with LPN ovenized quartz.

Unfortunately I can't say the same about the crystal on the motherboard.

I have the system configured so that ntpd and not the kernel disciplines
the system clock via PPS.  I understood this to be the preferred
method especially after reading PHK's papers.

Typical performance reported via ntpd's logging is <10 microseconds,
however I frequently see offset wander to around 25 microseconds.  I see
a strong correlation with temperature, even in an environmentally
controlled machine room.  I was even able to show a correlation to
outside temperature after one very cold morning in the spring.

I would love to be able to read motherboard temperature and use it as
a secondary statistic in the ntpd control loop.  Unfortunatly I've
put the ntp server project down for a while so this tweek won't happen
for some time.

--Eric Brown