"David J Taylor" <[EMAIL PROTECTED]> writes: >Unruh wrote: >[] >> An hour later, it was still 7ms off, another hour, 2.6ms and another >> hour >> later, still 1.2 ms off. Ie, only after about 6 hours was it within a >> ms of >> the correct time. Now, usually this PPS controls the time to within >> about 2us (not ms, usec) but it is apparently going to take over 10 >> hours to get >> there. That is of course completely rediculous.
>There sounds to be something wrong with your system. Nope, it is not my "ssytem" if by that you mean my computer. The convergence is a beautiful exponential convergence with a time scale of 1 hour almost exactly. That is not hardware. That is the software ntp protocol. >As a comparison, I have a very old Pentium 133 system here running FreeBSD >with local GPS PPS and some other Internet-based stratum 2/3 servers >(probably NTP pool and a fixed name). I'm sure it's well within a few >minutes for it to reach it's full accuracy (tens of microseconds). For >interest, I've just (0645 UTC) switched it off and on, and we will be able >to watch its recovery here (30 minute updates): Try switching it off, changing the value int he drift file by say 50PPM and then switching it on again, and see how long it takes to recover from that. Note, if you are running gps, why have a poll level 6? The recommendation for ref- clocks is poll level 4? > http://www.satsignal.eu/mrtg/pixie_ntp.html >Here it is about a minute after startup: >ntpq -p pixie > remote refid st t when poll reach delay offset >jitter >============================================================================== >+calx.pulsewidth 193.120.10.3 2 u 62 64 1 22.272 1.700 >0.743 >+admin.islay.bit 192.33.96.102 2 u 62 64 1 21.131 0.921 >1.112 >+dnscache-london 128.250.33.242 2 u 62 64 1 22.845 3.299 >0.666 > 88-96-233-89.ds .PPS. 1 u 14 128 7 63.431 0.044 >2.789 >*utserv.mcc.ac.u 193.62.22.98 2 u 64 64 1 26.494 4.312 >0.829 > GPS_NMEA(1) .PPS. 0 l 12 64 3 0.000 -0.137 >1.654 >.. and a few minutes later ... >ntpq -p pixie > remote refid st t when poll reach delay offset >jitter >============================================================================== >+calx.pulsewidth 193.120.10.3 2 u 54 64 37 22.348 2.946 >0.877 >+admin.islay.bit 192.33.96.102 2 u 53 64 37 20.496 1.862 >1.057 >+dnscache-london 128.250.33.242 2 u 57 64 37 23.090 3.809 >0.662 > 88-96-233-89.ds .PPS. 1 u 134 256 17 63.431 0.044 >2.007 >+utserv.mcc.ac.u 193.62.22.98 2 u 53 64 37 25.564 5.371 >0.868 >*GPS_NMEA(1) .PPS. 0 l 3 64 77 0.000 -0.001 >0.803 >It's using the out-of-the-box NTP code, and probably a rather old version >of NTP. > version="ntpd 4.2.0-a Sun May 8 06:01:21 UTC 2005 (1)" >It's a very simple system, described here: > http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm And I am using 4.2.4p4 >Cheers, >David _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
