[ntp:questions] Dave Hart Windows PPS patch set and Atom driver

hvengel at astound.net hvengel at astound.net
Tue Jun 2 01:12:48 UTC 2009

On May 31, 1:18 pm, "David J Taylor" <david-tay... at blueyonder.not-this-
part.nor-this.co.uk.invalid> wrote:
> hven... at astound.net wrote:
> > Just a quick follow up.  Dave has supplied me with some updated code
> > and this seems to be working OK on my machine now.  It appears that
> > most of the issue I was seeing was corrected when I turned serial port
> > buffering off.  At this point I am using the Atom (PPS) driver on
> > Windows since the Oncore driver is not working at this time.
> Thanks for reporting back.  Good of Dave to find time to help, and good
> that we are gradually extending the Windows support in NTP.  My thanks to
> all that are helping.
> David

Of course this is still all very new on Windows and it will take time
to mature.  So I was not real surprised when I couldn't get it to work
initially.  Hopefully others will test this and if they have any
issues will work with Dave to fix them.

On Windows I am now seeing sub-millisecond offsets once things
stabilize.  This takes about 2 hours.  This is not nearly as good as
what I see on Linux with my heavily tweaked system.  It reports sub-
microsecond offsets after it has stabilized and this typically happens
in less than 15 minutes.  Jitter is higher than what I see on Linux at
around 10us to 15us compared to 1us on Linux.  But it is a big
improvement over the time keeping on Windows with no PPS device where
I was typically having offsets in the 5ms to 15ms range using hand
selected public time servers (using only pool servers I would expect
this to be 15ms to 30ms).

The other thing I ran into is that I had some issues keeping the PPS
selected by NTP.  This is not a Windows specific issue.  I was using
near by (IE. low latency) public stratum 1 servers and the offsets
clustered so close together that the PPS was an outlier much of the
time.  I "fixed" this by only using one of the stratum 1 servers and
designating it as the "prefer" peer.  Then using additional pool
servers which the intention that these would be more likely to end up
being outliers because they would have higher latency, offsets and
jitter.  And that this would increase the likely hood that the PPS
would not be an outlier.  This seemed to work.  I also had to increase
the mindisp setting otherwise it would take a long time for ntp to
start using the PPS.

In some ways the Atom driver is flawed in that it makes some
assumptions about how the PPS is related to the prefer peer and also
assumptions about the viability of the PPS itself based on that
assumed relationship.  In my case the PPS is from a timing device that
is configured to monitor the quality of the PPS and to disable the PPS
is it is not working correctly (TRAIM and position hold are turned
on).   The flaw is that the driver makes the assumption that the PPS
is trustworthy if the prefer peer is working but is otherwise not to
be trusted.  This may be true for some combinations like a NMEA GPS
with an always on PPS pulse where the NMEA GPS is the prefer peer.
But if the prefer peer is an external NTP server then the viability of
the prefer peer does not tell us anything about the quality of the PPS
source and the assumption breaks down.  The flip side is that with a
device like a timing Oncore the PPS can be setup to only appear if
things are working correctly and under those conditions the prefer
peer tells us nothing about the quality of the PPS.  These are not
fatal flaws but users need to understand these limitations to get the
most of of this driver.   I don't know how to solve this issue other
then that it would go away for me if the Oncore driver was working on
Windows (IE is it not an issue for me on Linux).  Hopefully this will
happen at some point soon.

More information about the questions mailing list