[ntp:questions] NTP.conf using Dave Hart code.
davehart at gmail.com
Tue Feb 9 22:12:17 UTC 2010
On Feb 9, 20:19 UTC, BK <bkrei... at sigmatechcorp.com> wrote:
> One oddity about my configuration is that the NTP
> server will not be up 24x7. The machine will be booted, and I would
> like the ntpd to discipline the local clock to a reasonable (+-10ms)
> accuracy within 10 minutes. I have another machine that I will then
> synchronize to the computer with the GPS.
I'm not sure I understand the setup you're describing, but if you only
care about getting the clock within 10ms using the GPS+PPS, and are
then going to rely on a stratum 1 ntpd on the LAN and not use the GPS
+PPS after boot, you probably can do what you want without using the
GPS+PPS at all. By default, ntpd will step the clock at startup if it
is believed to be more than 128ms out, but that is a tunable number.
If you removed the refclock from ntp.conf, crank "tinker step 0.010"
and invoked ntpd with -q ("ntpdate mode"), it would step the clock if
it were more than 10ms off from the network source and then exit.
With properly-behaved ntpd across a LAN and 24x7 ntpds, offsets tend
to be a few ms, so for your requirement using GPS+PPS may not be worth
tying up the hardware.
> #tell NMEA reflclock to use RMC messages
> server 127.127.20.1 minpoll 4 mode 1
> # tell NMEA refclock to use PPS
> fudge 127.127.20.1 refid gps stratum 1 flag1 1
> It really doesn't matter to me if I install the serialPPS driver or
> not. From your discussion it appears using the serialPPS driver is
> more accurate than the NMEA driver? Does that make it a better choice
> or is that just making it more confusing?
No, I make it more confusing. :) Given your requirement that the GPS
will send both RMC and GGA every second, the simple answer is the PPS
is unavailable without PPSAPI/serialpps.sys, because of the once-per-
second limitation of the way PPS timestamps replace end-of-input-line
timestamps on Windows. That's not quite true, though. Assuming your
GPS is consistent in the order of the sentences, you're in luck
because ntpd's NMEA driver can use either sentence equally easily.
The end-of-input-line timestamp of the the _first_ after each PPS
event will be replaced with the PPS event timestamp. So if your GPS
is putting out RMC first then GGA, the configuration above should work
without "flag1 1" enabling PPSAPI or depending on serialpps.sys. If
it's putting out GGA before RMC, changing the mode appropriately
should allow it to produce low jitter figures indicating PPS is
Even using PPSAPI with "flag1 1", you will probably want to limit ntpd
to using whichever sentence comes first, as the PPS is not used until
the NMEA serial timestamps are consistent enough for ntpd to conclude
it has the clock within 0.4s and is safe to assume it knows which
second a PPS event is associated with.
More information about the questions