On Thu, Dec 1, 2011 at 00:27, Mark C. Stephens <[email protected]> wrote: > 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)
I'm glad you got it working well. Note that as the .zip modified timestamps suggest, 4.2.7p31 is a substantial _downgrade_ relative to 4.2.7p224. I recognize the sort order browsing the available versions is not ideal and could lead to this sort of confusion. Waiting an hour before quoting ntpq stats is wise if you want to show the best ntpd can do on Windows with PPS -- particularly if your system clock and performance counter have more frequency error than Mark's system. Unlike portable ntpd, the Windows version constructs a hybrid clock from the system clock augmented by the peformance counter when practical. This includes continuously fine-tuning the rate error of the counter over a long time constant selected to avoid perturbing portable ntpd's clock discipline. After an hour, the performance counter frequency correction has usually stabilized in my experience. You can monitor it with ntpq -crv or ntpq -c "rv 0 ctr_frequency". Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
