Re: [ntp:questions] Seeking help configuring GPS refclock
Correct; the interleaved modes, both symmetric and broadcast, are in the development version now. OK, thanks for clearing that up. Am I correct in understanding that interleaved symmetric mode would be useful if peers are on opposite sides of a cable or DSL modem infrastructure? -- 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 help configuring GPS refclock
Rich, The only thing interleaved modes avoid is the queuing, buffereing and transmission latencies on the local operating system, driver and interface card. It doesn't suppress errors due to network latencies. These modes were originally designed for space data links where time tag hardware is available and transmission rates are very low and for Ethernet NICs of the PCNET architecture.. Dave Rich Wales wrote: Correct; the interleaved modes, both symmetric and broadcast, are in the development version now. OK, thanks for clearing that up. Am I correct in understanding that interleaved symmetric mode would be useful if peers are on opposite sides of a cable or DSL modem infrastructure? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
The only thing interleaved modes avoid is the queuing, buffering and transmission latencies on the local operating system, driver and interface card. It doesn't suppress errors due to network latencies. Hmmmph. Yes, I see this now. Sorry I was confused earlier. As for the mysterious 8- to 10-msec discrepancy between my GPS clock and Stanford's campus NTP infrastructure, it turns out that Stanford's existing TrueTime GPS clock is old and is being phased out. My clock agrees very closely with a new Meinberg GPS clock which will become the new campus refclock soon. -- 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 help configuring GPS refclock
You misunderstand the usage of the xleave option which is still experimental. It requires (currently) IEEE-1588 hardware to work and it needs to be set up to send additional time-delay information down the same path as the ntp packet. I'm confused now, because the description of interleaved symmetric mode in http://www.eecis.udel.edu/~mills/onwire.html clearly claims that the NTP reference implementation does handle interleaved mode via software timestamps. Quoting from the introduction of the above page: The interleaved modes described in this section have been implemented and tested in the NTP reference implementation. In its present form only software timestamps (softstamps) are used, with the advantage that the actual transmit timestamp is captured upon return from the I/O routine and more accurately represents the on-wire hardware timestamp (hardstamp). Future plans include using driver timestamps or NIC timestamps as the opportunity arises. Thus, I assumed that if I had two servers, running ntp-dev and peering with each other, with the xleave option specified on each server for its association with the other server, they would use the two-step interleaved symmetric mode protocol described in the above web page (with software-generated time stamps) -- and that doing this should do a decent job of correcting automatically for asymmetry in the network connection, without needing to fudge the asymmetry explicitly -- and that the end result would be good as long as I wasn't expecting to get super-accurate, sub-microsecond sync (for which I admittedly would need special network cards with hardware timestamp capabilities). Am I mistaken here? -- 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 help configuring GPS refclock
Rich, Correct; the interleaved modes, both symmetric and broadcast, are in the development version now. They do not use 1588 hardware, although conceivably they could with appropriate NICs. They use what I call drivestamps, which are captured very close to the driver interrupt time. In configurations here interleaved modes whack anywhere from 15 microseconds to 400 microseconds off the output queuing, buffering and transmission delay. There is a chapter about it in my new book in progress. It has more analysis and performance measurements. If somebody wants to review and comment, I would be happy to provide a copy, but I don't want to broadcast it, as it is copyrighted. Dave Rich Wales wrote: You misunderstand the usage of the xleave option which is still experimental. It requires (currently) IEEE-1588 hardware to work and it needs to be set up to send additional time-delay information down the same path as the ntp packet. I'm confused now, because the description of interleaved symmetric mode in http://www.eecis.udel.edu/~mills/onwire.html clearly claims that the NTP reference implementation does handle interleaved mode via software timestamps. Quoting from the introduction of the above page: The interleaved modes described in this section have been implemented and tested in the NTP reference implementation. In its present form only software timestamps (softstamps) are used, with the advantage that the actual transmit timestamp is captured upon return from the I/O routine and more accurately represents the on-wire hardware timestamp (hardstamp). Future plans include using driver timestamps or NIC timestamps as the opportunity arises. Thus, I assumed that if I had two servers, running ntp-dev and peering with each other, with the xleave option specified on each server for its association with the other server, they would use the two-step interleaved symmetric mode protocol described in the above web page (with software-generated time stamps) -- and that doing this should do a decent job of correcting automatically for asymmetry in the network connection, without needing to fudge the asymmetry explicitly -- and that the end result would be good as long as I wasn't expecting to get super-accurate, sub-microsecond sync (for which I admittedly would need special network cards with hardware timestamp capabilities). Am I mistaken here? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Rich Wales wrote: My experimental stratum-1 server (using a Garmin GPS as its reference clock) continues to run stably -- albeit with an offset several msec different from the rest of my home LAN (which is synced to Stanford University's time server infrastructure). remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l28 3770.000 -0.001 0.002 PPS(0) .PPS.9 l68 3770.0000.000 0.002 *iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871 Why is your PPS at stratum 9? It should be stratum 0. You need to fix that. You didn't provide a copy of your ntp.conf file so it's hard to tell how you got that. Once you fix that it should synch to your refclock. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Rich Wales wrote: Kevin Oberman wrote: I don't know what the path is from your location to Stanford's NTP server . . . . I'm in a Stanford-built housing complex immediately adjacent to the campus. The extra (and likely asymmetric) delay in my case is most likely happening because my residence is connected via a cable modem infrastructure run by the Stanford campus's IT services people. NTP assumes the same delay for the return packet that it had for the request packet. If that is not the case, you will see a fixed offset. The only fix is a 'fudge' of the time for that server. If the path is unstable, even that will not work. I thought the xleave feature in ntp-dev was supposed to compensate for asymmetric paths. All my systems are running ntp-dev and peering with one another with xleave specified. You misunderstand the usage of the xleave option which is still experimental. It requires (currently) IEEE-1588 hardware to work and it needs to be set up to send additional time-delay information down the same path as the ntp packet. fudge is the right option if you know the amount of the asymmetry, which is hard to measure in the first place. For some reason I am having difficulty finding the fudge option in the html documentation but it should describe this. Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Why is your PPS at stratum 9? It should be stratum 0. I intentionally fudged the PPS refclock to stratum 9 so it wouldn't get picked. I wanted to force the server to pick the GPS_NMEA refclock. Actually, with PPS support enabled in the GPS_NMEA driver (flag1 = 1), I finally realized I don't need the separate PPS refclock anyway -- the GPS_NMEA driver deals with the PPS just fine all by itself -- so I took it out a couple of days ago. -- 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 help configuring GPS refclock
My experimental stratum-1 server (using a Garmin GPS as its reference clock) continues to run stably -- albeit with an offset several msec different from the rest of my home LAN (which is synced to Stanford University's time server infrastructure). remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l28 3770.000 -0.001 0.002 PPS(0) .PPS.9 l68 3770.0000.000 0.002 *iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871 In an attempt to compare my results with something (and get some idea of which of us -- the campus server or my own -- is more likely correct), I set up a second test server here at home, using a Conexant HCF modem (a PCI device) phoning NIST in Colorado. The results from this setup appear disappointingly unstable (several msec jitter even after running all night), but the modem refclock seems to be more in agreement with the campus clock than with mine. Here are a few ntpq -p outputs from this second system (I've omitted some of my home LAN systems from the peer list to reduce clutter somewhat). remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u 13 16 3760.1030.327 0.018 +iknow.richw.org 171.64.7.115 3 u 60 64 376 10.593 -8.087 1.696 ACTS_MODEM(0) .NIST. 0 l 273 512 2770.000 -5.147 3.674 remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u5 16 3770.0970.127 0.014 +iknow.richw.org 171.64.7.115 3 u9 64 3779.888 -10.077 2.085 ACTS_MODEM(0) .NIST. 0 l 185 512 3770.000 -16.325 10.689 remote refid st t when poll reach delay offset jitter == *sixeyes.richw.o .GPS.1 u4 16 3770.0990.158 0.057 +iknow.richw.org 171.64.7.77 3 u2 64 3778.919 -9.841 1.103 ACTS_MODEM(0) .NIST. 0 l 120 512 3770.000 -5.147 5.961 The 171.64.7.* hosts in the above are stratum-2 servers at Stanford, which are in turn syncing to 171.64.7.87, a stratum-1 server with a TrueTime GPS receiver. Also, the delay reaching iknow.richw.org (on campus) is because I'm going through a cable modem -- but all my boxes are running ntp-dev and using xleave, which is why jitter to iknow.richw.org is low. I also checked the clockstats data on the server with the modem, and it reported timestamps ending in # (delay correction valid). I can post some of this data if anyone thinks it would matter. So, at this point, what basis (if any) would I have to conclude that my test server is or isn't accurate? And if it isn't accurate, what should I do to fix the problem? Or, if the campus server is likely to be the falseticker, how would one go about establishing that fact? In case it might matter, I checked the geographical coordinates being output by my GPS against a satellite photo from Google Maps, and it's showing my exact location to within a few feet. And the GPS claims to be consistently seeing at least seven satellites. So I would assume my GPS unit is working properly -- except for the above evidence that seems to suggest its time is off. Any thoughts or suggestions welcomed. -- 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 help configuring GPS refclock
Date: Mon, 03 Aug 2009 07:52:39 -0700 From: Rich Wales ri...@richw.org Sender: questions-bounces+oberman=es@lists.ntp.org My experimental stratum-1 server (using a Garmin GPS as its reference clock) continues to run stably -- albeit with an offset several msec different from the rest of my home LAN (which is synced to Stanford University's time server infrastructure). remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.0 l28 3770.000 -0.001 0.002 PPS(0) .PPS.9 l68 3770.0000.000 0.002 *iknow.richw.org 171.64.7.115 3 u 10 16 376 10.058 -9.249 3.871 I see a couple of things here. First, almost 4 ms. of jitter is excessive for a stable, uncongested network link. I don't know what the path is from your location to Stanford's NTP server, but at 10 ms. delay, it's a few hundred miles. I suspect that the link is congested at some point and, more significantly, I suspect that it is asymmetric. NTP assumes the same delay for the return packet that it had for the request packet. If that is not the case, you will see a fixed offset. The only fix is a 'fudge' of the time for that server. If the path is unstable, even that will not work. If the congestion that is producing the jitter is pretty consistent, it will null out eventually, with a small offset it the congestion is only in one direction (which it usually is). From where I sit in Berkeley, I see the Stanford system 4.5 ms. away and a std. deviation of only .168 ms., so I suspect the congestion may be closer to you. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: ober...@es.net Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
Kevin Oberman wrote: I don't know what the path is from your location to Stanford's NTP server . . . . I'm in a Stanford-built housing complex immediately adjacent to the campus. The extra (and likely asymmetric) delay in my case is most likely happening because my residence is connected via a cable modem infrastructure run by the Stanford campus's IT services people. NTP assumes the same delay for the return packet that it had for the request packet. If that is not the case, you will see a fixed offset. The only fix is a 'fudge' of the time for that server. If the path is unstable, even that will not work. I thought the xleave feature in ntp-dev was supposed to compensate for asymmetric paths. All my systems are running ntp-dev and peering with one another with xleave specified. The Stanford campus tickers are running production versions of ntpd (and thus not using xleave, and I'm not peering to them anyway), but I assumed I could minimize the effects of the cable modem asymmetry by syncing to the campus NTP infrastructure from iknow.richw.org (which is in my office on the main campus network and connected to my home LANvia a VPN link), and then peering between iknow and my other hosts (located physically at home) using the xleave feature in ntp-dev. In any case, when I did my experiment last night with a second server (using a modem refclock), both of my stratum-1 servers were at home -- sitting next to each other on the same table and plugged into the same 100baseT switch -- so there shouldn't have been any network delays to speak of between them -- and they still appeared to differ by several milliseconds. -- 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 help configuring GPS refclock
On Sat, Aug 1, 2009 at 4:41 AM, Rich Walesri...@richw.org 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
Re: [ntp:questions] Seeking help configuring GPS refclock
Dave Hart wrote: The GPS refclock is using end-of-line timestamps . . . . 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. Thanks. I've done this, and the clockstats file shows it is now using the $GPRMC sentences. However, the offset is basically unchanged -- still around -670. How do I change the baud rate on this device? I tried a $PGRMC command with the tenth parameter equal to 5 (19200 baud), but it had no effect. I also tried connecting (via cu) at different baud rates, and issuing commands (thinking it might autodetect the speed of received data), but that also didn't change anything. 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. OK, I'll wait and see what it's looking like in the next day or two. -- 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 help configuring GPS refclock
On Sat, Aug 1, 2009 at 7:48 AM, Rich Walesri...@richw.org wrote: How do I change the baud rate on this device? I tried a $PGRMC command with the tenth parameter equal to 5 (19200 baud), but it had no effect. I also tried connecting (via cu) at different baud rates, and issuing commands (thinking it might autodetect the speed of received data), but that also didn't change anything. After instructing it to use a different baud rate, you have to reset the device for it to take effect, either by issuing a reset command, or by power cycling it. Also, once you have it talking at a rate other than 4800 bps, you'll need to inform ntpd to open the port at that rate by using an appropriate mode value on the server 127.127.20.1 line. Note the mode value is a combination of sentence selection bits and a bit rate selection, see driver20.html for details. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Seeking help configuring GPS refclock
After instructing it to use a different baud rate, you have to reset the device for it to take effect, either by issuing a reset command, or by power cycling it. OK, thanks. I'll try that. I gather that the Garmin GPS has some flash RAM (or a builtin backup battery), so it retains its settings even if power is removed? Also, once you have it talking at a rate other than 4800 bps, you'll need to inform ntpd to open the port at that rate by using an appropriate mode value on the server 127.127.20.1 line. Right. I saw that in the NTP documentation. I tried it early on, thinking that perhaps the driver would use the mode value to set the GPS's baud rate -- but, of course, that didn't work. Before I try resetting the baud rate, here's what the GPS currently looks like on my test server (sixeyes.richw.org). The jitter values have gone way down, but the GPS offset is still high (even with the mode set to look at only $GPRMC), and the PPS offset still differs by several msec from Stanford's clock. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l9 16 3770.000 -629.69 4.781 xPPS(0) .PPS.8 l6 16 3770.0003.811 0.055 +liberation.rich 10.0.229.53 5 u3 16 3772.196 -0.244 0.695 +whodunit.richw. 10.0.229.114 4 u 12 32 3772.211 -0.264 0.423 *iknow.richw.org 171.64.7.55 3 u9 32 3779.242 -1.457 4.772 And on iknow.richw.org (the box my test server, sixeyes, is syncing to): remote refid st t when poll reach delay offset jitter == liberation.rich 10.0.229.53 5 u 10 3207.3880.785 0.000 whodunit.richw. 10.0.229.114 4 u 208 256 3767.1260.948 2.469 sixeyes.richw.o 127.0.0.1 13 u 16 32 3769.3751.419 1.033 +Avallone.Stanfo 171.64.7.87 2 u 241 1024 3770.756 -0.648 0.192 *caribou.Stanfor 171.64.7.87 2 u 150 1024 3770.796 -2.838 0.265 +dusk.Stanford.E 171.64.7.87 2 u 696 1024 3770.774 -0.560 0.273 In case it matters here, iknow is on the campus network (in my office), and it's linked via OpenVPN to my home LAN. I'm using interleaved mode to compensate for the fact that Internet service to my home goes through a cable modem infrastructure. And, finally, the view from grandfather.stanford.edu (the stratum-1 server which Stanford's stratum-2 boxes are syncing to): remote refid st t when poll reach delay offset jitter == *TRUETIME(1) .GPS.0 l8 64 3770.000 -0.741 1.203 +bigben.cac.wash .USNO. 1 u 678 1024 377 21.6879.502 0.177 +clock.isc.org .GPS.1 u 688 1024 3774.7062.829 0.131 You might remember I brought up the issue, some time ago, of how the University of Washington's server (bigben) appears to be way off. -- 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 help configuring GPS refclock
OK, I reset my GPS to 19200 baud and configured it to emit only $GPGGA sentences, along with a 100-msec-wide PPS. I also changed ntp.conf to poll GPS and PPS every 8 (instead of 16) seconds. It's been running for about an hour now, and the jitters are pretty low. Here's a current result of running ntpq -p. remote refid st t when poll reach delay offset jitter == xGPS_NMEA(0) .GPS.9 l78 3770.000 -604.42 11.346 xPPS(0) .PPS.8 l68 3770.0004.354 0.017 +liberation.rich 10.0.229.53 5 u 15 16 3762.121 -4.407 0.527 +whodunit.richw. 10.0.229.114 4 u 15 64 3762.142 -4.146 0.345 *iknow.richw.org 171.64.7.55 3 u 56 64 3768.176 -4.002 1.650 Even with the baud rate increase, the GPS offset is still almost as big as it was before. And the difference between my local PPS's offset and that of one of my systems (iknow) which is on our campus network and is synced to one of our campus stratum-2 servers still seems significant, even after letting my server run long enough that the jitter is really small. In case it might help, here's the rl 0 output for my test server: associd=0 status=00f8 leap_none, sync_unspec, 15 events, no_sys_peer, version=ntpd 4.2.5p...@1.1934-o Tue Jul 28 05:47:52 UTC 2009 (1), processor=i386, system=FreeBSD/7.2-RELEASE, leap=00, stratum=13, precision=-19, rootdelay=0.000, rootdisp=5.000, refid=127.0.0.1, reftime=ce1f0d49.d72897dd Sat, Aug 1 2009 11:51:53.840, clock=ce1f0e0a.62d9013b Sat, Aug 1 2009 11:55:06.386, peer=0, tc=6, mintc=3, offset=-4.244, frequency=91.117, sys_jitter=1.548, clk_jitter=5.218, clk_wander=0.441, tai=34, leapsec=20090101, expire=20091228 and a peer listing from my system iknow.richw.org (mentioned above): remote refid st t when poll reach delay offset jitter == liberation.rich 10.0.229.53 5 u2 1607.3880.785 0.000 whodunit.richw. 10.0.229.114 4 u 70 256 3766.857 -0.267 0.779 sixeyes.richw.o 127.0.0.1 13 u 19 64 3778.1293.979 1.684 +Avallone.Stanfo 171.64.7.87 2 u 249 1024 3770.8081.907 0.932 *caribou.Stanfor 171.64.7.87 2 u 284 1024 3770.9520.456 1.109 +dusk.Stanford.E 171.64.7.87 2 u 806 1024 3770.8161.740 0.897 and the result of rl 0 from iknow.richw.org: associd=0 status=0615 leap_none, sync_ntp, 1 event, clock_sync, version=ntpd 4.2.5p...@1.1881-o Tue Jun 16 21:48:24 UTC 2009 (1), processor=i686, system=Linux/2.6.28-13-generic, leap=00, stratum=3, precision=-21, rootdelay=1.303, rootdisp=70.961, refid=171.64.7.55, reftime=ce1f0bc0.d5482987 Sat, Aug 1 2009 11:45:20.833, clock=ce1f0f62.afaa1862 Sat, Aug 1 2009 12:00:50.686, peer=63920, tc=10, mintc=3, offset=0.456, frequency=-120.794, sys_jitter=1.109, clk_jitter=1.432, clk_wander=0.073, tai=34, leapsec=20090101, expire=20091228 and a peer listing from our campus stratum-1 server (171.64.7.87, grandfather.stanford.edu): remote refid st t when poll reach delay offset jitter == *TRUETIME(1) .GPS.0 l 46 64 3770.000 -1.435 1.402 +bigben.cac.wash .USNO. 1 u 480 1024 377 21.6249.756 0.045 +clock.isc.org .GPS.1 u 488 1024 3774.7363.071 0.122 and the result of rl 0 from grandfather.stanford.edu: associd=0 status=0444 leap_none, sync_uhf_radio, 4 events, freq_mode, version=ntpd 4.2@1.1585-o Sun May 10 16:52:30 UTC 2009 (1), processor=i686, system=Linux/2.6.18-6-686, leap=00, stratum=1, precision=-20, rootdelay=0.000, rootdispersion=5.384, peer=11864, refid=GPS, reftime=ce1f0d2b.007d3962 Sat, Aug 1 2009 11:51:23.001, poll=10, clock=ce1f0d53.390640e8 Sat, Aug 1 2009 11:52:03.222, state=4, offset=-1.871, frequency=91.237, jitter=1.968, noise=1.791, stability=0.000, tai=0 -- 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 help configuring GPS refclock
I found the solution to my large GPS offset. It turns out that I needed to enable PPS signal processing in the GPS driver: fudge 127.127.20.0 flag1 1 I had somehow gotten the misimpression that if I was using the separate PPS driver (server 127.127.22.0), that meant I didn't need or want to deal with PPS in the GPS driver. But no. My ntpq -p output is much saner now: remote refid st t when poll reach delay offset jitter == oGPS_NMEA(0) .GPS.9 l68 3770.000 -0.008 0.002 xPPS(0) .PPS.8 l38 3770.000 -0.008 0.002 +liberation.rich 10.0.229.53 5 u8 16 3772.131 -5.080 3.003 +whodunit.richw. 10.0.229.114 4 u 12 16 3762.325 -4.996 8.129 *iknow.richw.org 171.64.7.89 3 u 14 16 3769.099 -6.797 8.415 I still seem to be several milliseconds different from the Stanford campus time source; this is going to require further investigation. -- 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
[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
