[ntp:questions] like a kid with a new toy (PPS jitter)

Dave Hart davehart at gmail.com
Mon Feb 9 00:40:46 UTC 2009


On Feb 8, 12:12 pm, Chris <givemeafckingacctyoudou... at gmail.com>
wrote:

> I'd be very interested to know your implementation in windows for
> capturing the PPS pin. I'm currently using a FreeBSD box and syncing
> windows boxes around it, but I'd much rather be able to sync my
> windows servers directly to the device for a few of the critical
> servers. Any chance you'd share your methods, or at least give some
> hints? I'm well versed in the Windows API, so that shouldn't be a
> problem. I just assumed that you'd need a kernel driver for this sort
> of syncing.

Well, a modified serial driver that would timestamp CD transitions
would be ideal and would give better results than I'm getting.  That's
not really practical unless you can start with Microsoft's existing
serial.sys code (it may be in the DDK, I don't know).  What I've done
is patch ntpd serial code for Windows to better emulate unix tty line
discipline, where a read returns at each end of line.  I've done this
using WaitCommEvent and dcb.EventChar set to CR.  The sources (a few
days old) and binaries (very recent) for my patched ntpd for Windows
are on http://davehart.net/refclock/

The PPS implementation (hack) fell out of this design.  Instead of
waiting for just the event character, the code always waits for
changes to the CD line.  When it transitions on, a timestamp is
taken.  When a serial refclock next reads a line from the serial port,
instead of timestamping the arrival of the CR, the PPS-on-CD timestamp
is used instead if one has been taken since the last line was read.
So this makes any serial refclock with PPS on the CD line act as a PPS-
controlled refclock.  It is not the preferred design, of course,
because it's not getting a timestamp at interrupt time, and also
because there is a move to get PPS functionality out of individual
refclock drivers and use the separate ATOM refclock for the PPS
aspect.  Now my change doesn't use any PPS functionality in the
reflclock driver, it just causes the reflock to appear to complete
reading a line of text at the time of the PPS signal.  It sounds like
you might want to share the PPS signal among several hosts with only
one getting the serial data pins connected.  In that case, what you
really need is a bit of work to provide a PPS-only refclock on
Windows, presumably using the ATOM driver.  I'm sure it can be done,
it's just a matter of doing it cleanly enough to be accepted into the
ntp reference implementation.  Are you contemplating bringing just PPS
to the Windows boxes or PPS+serial?

The binares on http://davehart.net/refclock/ have other patches as
well as the serial code.  They should behave better on Vista machines
(assuming -M on the command line as defaulted by Meinberg's installer)
by disabling nanokernel-like interpolation when it can't possibly work
well.  Other Windows machines should benefit from changing the
interface to return the (possibly synthesized) time of day to the
portable ntp code from timeval / microsecond resolution to timespec /
nanosecond resolution.  The interpolation calculates the time
internally using Win32 units of 100 ns, so-called hectonanoseconds,
but without my patch always rounds off the tenths-of-a-microsecond
component before returning it to the portable ntpd code.  That allowed
one machine I tested on to go from precision=-20 to -21, which is an
exponent of 2, so from about a microsecond to about 500 nanoseconds.
Additionally the interpolation scheme is marginally improved by
filtering outlying samples of time/counter correlations.  The biggest
downside is the patched binaries are chatty to the eventlog/ntp.log,
particularly about the filtering.  I encourage anyone using ntpd on
windows to give them a whirl and report back.

Cheers,
Dave Hart




More information about the questions mailing list