Date: Sat, 31 Jul 2004 16:19:08 -0700 From: "Kevin Oberman" <oberman@es.net> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-stable@freebsd.org Subject: Re: Looking for ntp/PPS setup guide Message-ID: <20040731231908.18F485D08@ptavv.es.net> In-Reply-To: Your message of "Sat, 31 Jul 2004 14:46:27 MDT." <20040731.144627.06076085.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Sat, 31 Jul 2004 14:46:27 -0600 (MDT)
> From: "M. Warner Losh" <imp@bsdimp.com>
>
> In message: <20040730000205.E834A5D09@ptavv.es.net>
> "Kevin Oberman" <oberman@es.net> writes:
> : > From: Gregory Bond <gnb@itga.com.au>
> : > Date: Fri, 30 Jul 2004 09:38:32 +1000
> : > Sender: owner-freebsd-stable@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@es.net Phone: +1 510 486-8634
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040731231908.18F485D08>