Upgraded to
Version: Tuesday, May 11, 2010 10:22 AM 836048
ntp-4.2.7p31-win-x86-bin.zip
Result: Is the GPS_NMEA broken?
Event log: GPS_NMEA(1) 801b 8b clock_event clk_bad_format
GPS_NMEA(1) 801b 8b clock_event clk_no_reply
GPS_NMEA(1) serial /dev/gps1 open at 9600 bps
Was working before so apply the n-1 theory:
Version: Saturday, October 15, 2011 3:32 AM 932341
ntp-4.2.7p224-win-x86-bin.zip
Result: Bingo! (I think)
C:\Program Files\NTP\bin>ntpd -n -M -g -c "C:\Program Files\NTP\etc\ntp.conf"
1 Dec 10:24:50 ntpd[6028]: ntpd 4.2.7p224-o Oct 14 19:58:02.91 (UTC-00:00)
2011 (1)
1 Dec 10:24:50 ntpd[6028]: Raised to realtime priority class
1 Dec 10:24:50 ntpd[6028]: MM timer resolution: 1..1000000 msec, set to 1 msec
1 Dec 10:24:50 ntpd[6028]: Performance counter frequency 1263.420 MHz
1 Dec 10:24:50 ntpd[6028]: Clock interrupt period 15.625 msec (startup slew
0.1 usec/period)
1 Dec 10:24:50 ntpd[6028]: Windows clock precision 15.625 msec, min. slew
6.400 ppm/s
1 Dec 10:24:50 ntpd[6028]: HZ 64.000 using 43 msec timer 23.256 Hz 64 deep
1 Dec 10:24:53 ntpd[6028]: proto: precision = 0.800 usec
1 Dec 10:24:53 ntpd[6028]: Listen and drop on 0 v4wildcard 0.0.0.0:123
1 Dec 10:24:53 ntpd[6028]: Listen normally on 1 NIC1 192.168.5.8:123
1 Dec 10:24:53 ntpd[6028]: Listen normally on 2 MS TCP Loopback interface
127.0.0.1:123
1 Dec 10:24:53 ntpd[6028]: peers refreshed
1 Dec 10:24:53 ntpd[6028]: GPS_NMEA(1) serial /dev/gps1 open at 9600 bps
time_pps_create(4) got winhandle 00000620
getenv(PPSAPI_DLLS) gives
c:\serialpps\serialpps-ppsapi-provider\x86\serialpps-ppsapi-provider.dll
loaded PPSAPI provider serialpps.sys, serial.sys with CD timestamping added
caps 0x3011 provider 00B6F5B0
serialpps prov_time_pps_create(00000620) returned 0
1 Dec 10:24:53 ntpd[6028]: 0.0.0.0 c012 02 freq_set ntpd 5.798 PPM
1 Dec 10:24:53 ntpd[6028]: 0.0.0.0 c016 06 restart
1 Dec 10:24:54 ntpd[6028]: 0.0.0.0 c415 05 clock_sync
1 Dec 10:37:27 ntpd[6028]: ctr 1263.412 MHz -6.46 PPM using 1263.417 MHz
-2.15 PPM
Within the hour:
remote refid st t when poll reach delay offset jitter
==============================================================================
*GPS_NMEA(1) .GPS. 0 l 7 16 377 0.000 0.013 0.052
Best performance I have seen.
As with all things NTPD I will report back in a day or so..
Mark
-----Original Message-----
From: Dave Hart [mailto:[email protected]]
Sent: Thursday, 1 December 2011 1:51 AM
To: Mark C. Stephens
Cc: [email protected]
Subject: Re: [ntp:questions] windows device manager and serialpps.sys
On Tue, Nov 29, 2011 at 14:54, Mark C. Stephens <[email protected]> wrote:
> I am running 4.2.7p98-o and I am uncertain whether or not PPS is working.
That's a relatively antique snapshot of ntp-dev. At least with more recent
ntp-dev, if PPSAPI is enabled for NMEA using flag1 1 as you have, the NMEA
refclock driver will log an error message on startup if PPSAPI is not working
that mentions both PPSAPI and flag1 1. See your event log or a configured
ntp.log.
There are less direct things you could try, like see if manually lowering the
ntpd process priority class from Realtime to Low then throwing some work at the
machine increases the offset ntpd reports for the NMEA association. If PPSAPI
is working the timestamps are snapped at serial port interrupt time and will
not be affected by additional ntpd scheduling latency.
Cheers,
Dave Hart
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
