Re: [ntp:questions] Solaris 8 xntpd vs ntpd?
Unruh wrote: > David Woolley writes: > >> Unruh wrote: > >>> xntp is ntpd 3 as far as I know. The current ntp is ntp 4 which has a >>> lot of improvements and changes. ntp4 is the only version which is >>> supported. > >> I assume that Sun support the NTP V3 implementation that they supply, >> and wouldn't support the current one, installed lcoally. > > And exactly what Sun support do you expect to get? Sun is not an expert > on ntp. Well, as the Sun NTP lead engineer, let me just say "Hurrumph"! But more to the point, Solaris 8 is no longer supported. It is a perfect match, an ancient OS with an ancient NTP version. Really, why are you using Solaris 8? Use OpenSolaris. It comes with NTP 4.2.5p172 already installed and fully supported. Brian Utterback ___ 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
> Date: Mon, 03 Aug 2009 07:52:39 -0700 > From: Rich Wales > 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
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
