Re: [ntp:questions] Seeking help configuring GPS refclock
On Sat, Aug 1, 2009 at 4:41 AM, Rich Wales wrote: > I recently bought a Garmin GPS 18x LVC and am trying to set it up > as a reference clock, but I'm running into some strange results. [...] > I've configured the unit to utter $GPRMC and $GPGGA sentences at > 4800 baud, with a 100-msec PPS signal. [...] > First, why is the GPS refclock's offset so big (-655.20)? The GPS refclock is using end-of-line timestamps, and it takes about 300 msec at 480 octets per second to transmit the two sentences (totaling ~143 octets including CR/LF), both of which are understood by the NMEA refclock driver, resulting in the later EOL timestamp being used each second. If you configure the GPS to send only one sentence, or increase the serial bitrate, the offsets should come closer to zero. Rather than change the GPS to send a single sentence, you could configure the NMEA refclock to ignore all but the first one it sends, in this case $GPMRC, using "mode 1" on the "server 127.127.20.1" line. > And second, why is the PPS offset off by several milliseconds from > the Stanford-synced hosts? Does this mean that Stanford's campus NTP > infrastructure is misconfigured and measurably off, and I'm right? > Or is it possible that I'm somehow set up wrong? The jitter figures you quoted were larger than the corresponding offsets for the Stanford associations. Wait for the jitter to be substantially less than the offset, and consider the offset to have an error band as wide as the jitter, before comparing the Stanford offsets with the PPS. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Seeking help configuring GPS refclock
I recently bought a Garmin GPS 18x LVC and am trying to set it up as a reference clock, but I'm running into some strange results. Specifically, the GPS time seems to be way off, and the PPS is several milliseconds different from what I thought was a pretty accurate local stratum-1 server. I've hooked up the GPS signal lines as described here: http://www.satsignal.eu/ntp/FreeBSD-GPS-PPS.htm (I'm pulling the required +5VDC power from a USB port.) I've configured the unit to utter $GPRMC and $GPGGA sentences at 4800 baud, with a 100-msec PPS signal. I'm using ntpd 4.2.5p195 on an 800-MHz Dell box running FreeBSD 7.2 (using a custom kernel with PPS support enabled). This system is really not doing anything else other than running ntpd; "top" shows it to be 99+% idle, using no swap and almost no RAM. The relevant lines from ntp.conf are as follows. (For the moment, I'm intentionally specifying a high stratum to prevent any host on my LAN from syncing to this experimental system.) The 10.0.229.* hosts are on my LAN; they're all Ubuntu 9.04 (Jaunty) boxes running ntpd 4.2.5p181 and syncing to Stanford University's NTP servers. server 127.127.20.0 minpoll 4 maxpoll 4 version 4 fudge 127.127.20.0 refid GPS stratum 9 server 127.127.22.0 minpoll 4 maxpoll 4 version 4 fudge 127.127.22.0 refid PPS stratum 8 peer 10.0.229.29 minpoll 4 maxpoll 6 key 2 xleave peer 10.0.229.53 minpoll 4 maxpoll 6 key 2 xleave peer 10.0.229.114 minpoll 4 maxpoll 8 key 2 xleave Now . . . here's some output from "ntpq -p" on my experimental box. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l5 16 3770.000 -655.20 2.257 xPPS(0) .PPS.8 l3 16 3770.0005.844 0.004 +liberation.rich 10.0.229.53 5 u 15 64 3772.208 -0.652 0.769 +whodunit.richw. 10.0.229.114 4 u 16 64 3772.219 -0.195 0.665 *iknow.richw.org 171.64.7.89 3 u 41 128 3758.1470.756 2.690 I'm confused about two things here. First, why is the GPS refclock's offset so big (-655.20)? And second, why is the PPS offset off by several milliseconds from the Stanford-synced hosts? Does this mean that Stanford's campus NTP infrastructure is misconfigured and measurably off, and I'm right? Or is it possible that I'm somehow set up wrong? In case it might help, here is a bit of sample output from my GPS (from a "cu" session). If I'm interpreting this right, it looks like I'm seeing 8 satellites and ought to be getting high accuracy. $GPRMC,013257,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*65 $GPGGA,013257,3726.2063,N,12210.8019,W,2,08,0.9,38.1,M,-32.4,M,,*45 $GPRMC,013258,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*6A $GPGGA,013258,3726.2063,N,12210.8019,W,2,08,0.9,38.0,M,-32.4,M,,*4B $GPRMC,013259,A,3726.2063,N,12210.8019,W,000.0,000.0,010809,015.0,E*6B $GPGGA,013259,3726.2063,N,12210.8019,W,2,08,0.9,38.0,M,-32.4,M,,*4A Any thoughts? -- Rich Wales / ri...@richw.org / ri...@stanford.edu Wikipedia: http://en.wikipedia.org/wiki/User:Richwales Facebook: http://www.facebook.com/richwales ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] seeking advice; NTP peers, GQ identities and Autokey
On Fri, Jul 31, 2009 at 08:00:02PM +, David Mills wrote: > Brian, > > The release version has a mixture of old > and new protocol modules that are incompatible. The old ones work and > the new ones work, but not a combination of the old and new as in the > current release version. Ah. So - assuming I'm stuck with our vendors release (RHEL packaged 4.2.2p1), which protocol modules modules would be most appropriate to manage peers? > The error code you cite is in facr at the spot you cited, but you > didn't notice the log code is in hex. No, I didn't. Thanks for pointing that out... I appreciate the feedback. I have, for now, collapsed back to the tried-and-true use of ntp.keys, to continue my experiments... > > Dave > -- Brian Reichert 55 Crystal Ave. #286Daytime number: (603) 434-6842 Derry NH 03038-1725 USA BSD admin/developer at large ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] seeking advice; NTP peers, GQ identities and Autokey
Brian, The first problem is the RH version, which is far older than the current release version and ancient relative to the development version. I say again for the umpteenth time, only the development version is expected to work correctly with Autokey. The release version has a mixture of old and new protocol modules that are incompatible. The old ones work and the new ones work, but not a combination of the old and new as in the current release version. The error code you cite is in facr at the spot you cited, but you didn't notice the log code is in hex. Dave Brian Reichert wrote: >Hello, hopefully someone has some advice. > >I'm trying to manage a pair of peers using GQ identities and unicast >authentication and AutoKey. > >The symptom(s) I observe, after the several seconds it takes from the >association's 'auth' field to go from 'bad' to 'ok': > >- the assocation reports the condition as 'reject' > >- the refid on each node alternates between .AUTH. and .CRYP. > >- my cryptolog reports 'error 10f opcode 201 ts 0 fs 524353', > which is regrettably not described here: > > http://www.eecis.udel.edu/~mills/ntp/html/authopt.html#err > >- the association claims the other node is 'unreachable'. I can > see debug messages flow between the two nodes, so I know there's > no connectivity problem. > >- my debug log shows that the 'flags' setting is 0x80041, even > though that's not showing up in the 'rv' command below. I > deconstructed that according to ntp_crypto.h, and it's obvious > that there are a lot of bits missing... > >I would definitely appreciate some suggested course of action... > >I've applied notes according to: > > http://support.ntp.org/bin/view/Support/ConfiguringAutokey > >and perhaps more closely, this thread: > > http://www.mail-archive.com/questi...@lists.ntp.isc.org/msg05140.html > >Some specifics: > >I'm using RedHat's ntp RPM: > > # rpm -q ntp > ntp-4.2.2p1-9.el5_3.2 > >My ntp.conf: > > driftfile /var/lib/ntp/drift > statsdir /var/log/ntpstats/ > statistics loopstats peerstats clockstats cryptostats > filegen loopstats file loopstats type day enable > filegen peerstats file peerstats type day enable > filegen clockstats file clockstats type day enable > filegen cryptostats file cryptostats type day enable > crypto pw ServerPassword randfile /dev/urandom > crypto ident 1950dc1.example.com > #crypto ident 1950qc1.example.com > keys /etc/ntp/keys > keysdir /etc/ntp > peer 1950qc1.example.com autokey > #peer 1950dc1.example.com autokey > >Obviously, the 'peer' entry differs on each host, as does the 'crypto >ident' entry. > >On each node, I created GQ keys: > > cd /etc/ntp > ntp-keygen -T -G -p ServerPassword -q ServerPassword > >I copied the ntpkey_* files to both hosts. > >I restarted ntpd on both hosts, using the '-g' and -d' flags. > > # ntpq -npcas > remote refid st t when poll reach delay offset jitter > == > 172.20.166.111 .AUTH. 16 u- 12800.0000.000 0.000 > > ind assID status conf reach auth condition last_event cnt > === >1 44420 e04f yes yes ok reject 4 > > # ntpq -n -c "rv 44420" > assID=44420 status=e04f unreach, conf, auth, 4 events, event_15, > srcadr=172.20.166.111, srcport=123, dstadr=172.20.166.101, dstport=123, > leap=11, stratum=16, precision=-20, rootdelay=0.000, > rootdispersion=21.332, refid=AUTH, reach=000, unreach=123, hmode=1, > pmode=1, hpoll=7, ppoll=10, flash=00 ok, keyid=3440123012, ttl=0, > offset=0.000, delay=0.000, dispersion=15937.500, jitter=0.000, > reftime=. Thu, Feb 7 2036 6:28:16.000, > org=. Thu, Feb 7 2036 6:28:16.000, > rec=. Thu, Feb 7 2036 6:28:16.000, > xmt=ce1b3e19.7e040ed8 Wed, Jul 29 2009 21:31:05.492, > filtdelay= 0.000.000.000.000.000.000.000.00, > filtoffset=0.000.000.000.000.000.000.000.00, > filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 > >Dunno if other information may be useful; please let me know... > > > ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
