[ntp:questions] NTP.conf using Dave Hart code.
davehart at gmail.com
Tue Feb 9 19:05:44 UTC 2010
On Feb 9, 18:32 UTC, BK <bkrei... at sigmatechcorp.com> wrote:
> I originally didn't install the ATOM/PPS driver. However when I
> looked, I wasn't getting a PPS line ntpq. Maybe that is ok, but I
> assumed that meant it wasn't seeing the PPS and thus installed the
> other driver.
I should be clear we've been talking about two different types of
drivers here. Typically people don't refer to installing reference
clock drivers, as they're built-in to ntpd at compile time. Using a
reference clock driver is done via "server 127.127.driver.unit" in
ntp.conf. In contrast, serialpps.sys is a Windows hardware driver for
serial ports and does need to be installed using the accompanying .bat
It is very difficult to speak in general terms about PPS issues as the
handling evolved over time. Please share the version number of the
ntpd you're using, which you can find with ntpq:
C:\ntp>ntpq -c "rv 0 version"
version="ntpd 4.2.7p18 at 1.2102-o Feb 09 4:24:57.42 (UTC-00:00) 2010
You can use a PPS signal on your serial GPS setup at least two ways
with the current ntpd that do not involve the PPS/atom driver 22.
First, you can enable PPSAPI use by the NMEA driver 20 using fudge
flag1 1, as documented.  On Windows only, the ntpd port has an
alternative for getting PPS timestamps via the serial DCD line that
does not require PPSAPI (and hence serialpps.sys). If you configure
your GPS to emit a single sentence per second (typically they default
to several) then ntpd will use the DCD transition timestamps it
captures using normal Windows serial APIs in place of the end-of-input-
line timestamps. That is not quite as accurate as can be achieved
with PPSAPI, but it works where the unsigned serialpps.sys kernel-mode
driver is not available.
> You suggest that I get rid of the PPS driver, and just use the NMEA
> driver. Perhaps I didn't have a properly configured ntp.conf.
> So if I go with your suggestion the appropriate NTP.conf would look
> like this?
> server 127.127.20.1 minpoll 4 prefer # NMEA serial port
I would not use prefer unless you're also using 127.127.22.1 (PPS/
> fudge 127.127.20.1 refid gps stratum 1
Again the stratum fudge is not changing anything, but if you want it
there for documentation and comparison with the hated local clock
driver at stratum 5, that's your call.
> How can you tell when ntpd is receiving the PPS signal or not?
If the 127.127.x.1 jitter figure in ntpq -p (the "peers billboard")
drops to a number well under 1.000 in ntpq (expressed in milliseconds)
then you're getting PPS from the refclock. If you are instead using
serial end-of-line timestamps, your jitter will likely be at least a
few milliseconds. In practice when everything is stabilized and the
load and temperature are not changing much, I'm seeing 0.003 in the
jitter column using NMEA without PPSAPI (no fudge flag1 1) on Windows
and 0.002 with PPSAPI. Two or three microseconds of noise error isn't
too shabby for a 400MHz pentium II box in its second decade of
service. The offset without PPSAPI is as close as 40us to the more
trustworthy PPSAPI offset, in good conditions.
More information about the questions