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

Mischanko, Edward T Edward.Mischanko at arcelormittal.com
Sun Jan 20 20:54:19 UTC 2013


David,

Jitter of .008 seems pretty good to me?
That's better than my FreeBSD box gets with PPS.
I realize that .000 would be preferable.  ;-)

Regards,
Ed
> 
> 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
> 
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions


More information about the questions mailing list