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

Chris givemeafckingacctyoudouche at gmail.com
Tue Feb 10 12:58:32 UTC 2009


On Feb 8, 7:40 pm, Dave Hart <daveh... at gmail.com> wrote:
> 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 onhttp://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 onhttp://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
Dave,

Interesting, short-term I may look at that as a solution. I don't
necessarily need to feed a single pin to multiple computers. Only one
of the Windows machines is critical, I could sync off that if I needed
to.

While I only have Windows 2003 DDK installed at the moment, they do
include a complete serial device driver source project.
I've only done very minor Windows driver programming, but I may try to
download the newest DDK and give it a whirl.

// This bit is the delta data carrier detect.  It is used to indicate
// that the data carrier bit (in this register) has *changed*
// since this register was last read by the CPU.
//
#define SERIAL_MSR_DDCD     0x08

and
 if (ModemStatus & (SERIAL_MSR_DCTS |
                           SERIAL_MSR_DDSR |
                           SERIAL_MSR_TERI |
                           SERIAL_MSR_DDCD)) {

I think the change would/could be done in modmflow.c or isr.c, but I'd
really have to do some reading to get comfortable with driver
programming. I'm not really sure how'd I'd signal an event to the ATOM
driver (perhaps through DeviceIoCtrl?)




More information about the questions mailing list