[ntp:questions] Windows-8/64 kernel-mode PPS not producing expected jitter improvement

David Taylor david-taylor at blueyonder.co.uk.invalid
Sun Jan 20 14:01:48 UTC 2013


Folks,

I have been trying out the signed 64-bit serialpps.sys device driver 
made available as a result of bug report 2108:

   https://support.ntp.org/bugs/show_bug.cgi?id=2108
 
http://support.ntp.org/people/burnicki/windows/serialpps-20120321-signed.zip

on a new 64-bit Windows-8 PC.  However, I am not completely convinced 
that the driver is working as intended, and wonder whether anyone else 
has tried this driver?  Without the driver, just using the DCD line 
alone, NTP is working as expected, with an averaged jitter of about 9 
microseconds.  Adding in the 64-bit serialpps.sys and ensuring that the 
PPSAPI_DLLS environment variable was correctly set, the averaged jitter 
was unchanged, but the drift (frequency offset) was about 1 ppm greater. 
  A new line appeared in the ntpq -p display:

C:\Users\David>ntpq -p stamsund
      remote           refid      st t when poll reach   delay   offset 
  jitter
==============================================================================
oPPS(1)          .PPS.            0 l   14   16  377    0.000    0.026 
  0.008
*GPS_NMEA(1)     .GPS.            0 l   13   16  377    0.000   -0.020 
  0.014
+pixie           .PPS.            1 u   20   32  377    0.311    0.046 
  0.023
-Alta            .PPS.            1 u   24   32  377    0.357    0.108 
  0.092
+FEENIX          .PPS.            1 u    7   32  377    0.310    0.049 
  0.426

with the "o" indicating that the kernel-mode was working correctly. 
What I was expecting was that with the kernel-mode serialpps.sys, the 
jitter would at least be different, and all being well the jitter would 
be somewhat less than with user-mode time-stamping.  That's what I've 
seen on other systems.  I see nothing in the Event Log which suggests 
that NTP isn't working as expected, but neither am I seeing the expected 
improvement.

Here is an extract from my ntp.conf:

# ATOM driver with serialpps.sys
server	127.127.22.1	minpoll 4 refid PPS flag3 1

# NMEA serial port driver - Garmin GPS 18x LVC
server	127.127.20.1	minpoll 4  mode 33  prefer

I have tried flag3 as both 0 and 1, and there is no difference.

It would be nice to mark this bug as VERIFIED, but with the results I 
have I am reluctant to do so.

(Perhaps I should count myself lucky that the motherboard actually still 
has a COM port header!)
-- 
Thanks,
David
Web: http://www.satsignal.eu



More information about the questions mailing list