[ntp:questions] How do I know my GPS-based NTP server is actually working properly?

Kevin Oberman oberman at es.net
Fri Nov 2 16:19:52 UTC 2007


> Date: Wed, 31 Oct 2007 13:19:46 -0400
> From: John Ioannidis <ntp at tla.org>
> Sender: questions-bounces+oberman=es.net at lists.ntp.org
> 
> 
> Yes, I know this sounds weird.  I've successfully set up my NTP server: 
> an old 850MHz P3 box running FreeBSD 6.2-STABLE (kernel built with 
> option PPS_SYNC), and a Garmin GPS-18LVC "hokey puck", powered off the 
> USB port, with its PPS wire connected to the serial port's DCD line (pin 
> 1 on the DB9 connector). /etc/ntp.conf reads:
> 
> 	server  127.127.20.1    mode 1 prefer
> 	fudge 127.127.20.1    time1 0.000 flag3 1 refid PPS
> 
> So far so good.  It seems to be keeping time and synchronizing to GPS. 
> But...
> 
> What's the proper way of telling whether the PPS signal is actually 
> having an effect?  That is, what behavior/measurements would show me 
> that the PPS signal is or is not being used? What should I be monitoring 
> (my guess would be "offset" and "jitter" from the netq -c rv output), 
> and what kind of statistical analysis would tell me whether PPS is or is 
> not being used?
> 
> Thanks,
> 
> /ji
> 
> PS: the easy way to disable the use of the PPS signal is to set flag3 to 
> 0, right?  Reloading a kernel and rebooting is a bit of a pain on 
> antiquated hardware.

On FreeBSD for PPS you want something like this:
server 127.127.5.1 prefer minpoll 4 maxpoll 4
fudge 127.127.5.1 time1 .010
server 127.127.22.1 minpoll 4 maxpoll 4

You will probably want to add a time fudge once you see how much the
processing delays the update of the data from the GPS. It is variable,
depending on the speed of the system, but probably around .01 sec.

For connected reference clocks the minpoll and maxpoll should be short,
hence the value of '4'.

The refid should be 'GPS', not 'PPS'. (Actually, it shouldn't be needed
at all. It should default to GPS.)

Once you have PPS configured, you should see:
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+NMEA GPS(1)     .GPS.            0 l    4   16  377    0.000    0.190   1.929
oPPS(1)          .PPS.            0 l   12   16  377    0.000    0.005   0.002

I'm guessing on the content of the 'remote' field for clock 20.

The 'o' on the PPS line indicates that it is 'training' the value of the
associated clock.

Make sure that your ntpd is built to include the needed drivers. By
default FreeBSD does not build the drivers. You need to re-build ntpd
with CLOCK_NMEA defined.
-- 
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
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
URL: <http://lists.ntp.org/pipermail/questions/attachments/20071102/938cdcca/attachment.pgp>


More information about the questions mailing list