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

Jason Rabel jason at extremeoverclocking.com
Fri Nov 2 17:43:04 UTC 2007


> 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?

Did you connect the data lines too? To receive the NMEA info, or just the
PPS line?

You don't need to run a separate config for the PPS as PPS support is built
into the NMEA driver.

Run 'ntptime' and 'ntpq -c rv' for more info on what's going on... If your
root dispersion is less than 1 then it's working. Also the refid should tell
you the source.

As others have suggested set your minpoll & maxpoll to 4 for the driver.
Also you might want / need to disable the FIFO for better stability / lower
jitter:

http://support.ntp.org/bin/view/Support/KnownHardwareIssues

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

'flag 3' is only a switch that lets you choose between the kernel's hard pps
(if you rebuilt your kernel with the appropriate options), or to use NTP's
built into disciplining (which filters longer and does other magic). There's
a big debate as to which works better and die hard fans on both sides, you
can try it both ways and see what works best for you.

There is no way to disable the PPS signal itself via any software switch, if
it's present on the line then its used.

Easiest thing would be to use just the generic kernel and ntp's filtering
(no fudge flags needed, though you might need to specify a time fudge due to
processing / cable delays.)

If you are familiar with NTP on linux then I'm sure you have run 'ntpstat'.
I took the source and made a couple little modifications to get it to
compile on FreeBSD (also just finding the source was a treasure hunt in
itself)... You can download it from:

http://files.extremeoverclocking.com/file.php?f=193

I've been meaning to make it a little more robust and fix some little issues
with the program, but it should do the job. It's a little more convient than
running other commands and deciphering all the raw info.




More information about the questions mailing list