Re: [ntp:questions] Syncing to nearby vs. faraway servers
Hi, Dave -- Replying to: > As you can see, bigben is on the order of 10ms off from the consensus, > at least from ntp.davehart.net's perspective on a verizon business-class > DSL. I had also considered that the offset could be due to asymmetric > routing, but given the same ~10ms offset seen from Stanford, and that > bigben's backup sources are .INIT., I'm guessing bigben's clock-winder > has left the building. OK, thanks for looking into this. > My association with ntp3.isc.org is using interleaved mode, and so > should be correcting for asymmetric delays. Interleaved mode is a feature of ntp-dev (soon to be released as 4.2.6), right? I'll be looking forward to being able to use this new goodie -- though, if I read the documentation right, it apparently works only with peer or broadcast associations and won't help me when I talk to servers (but it might be a reason for me to encourage my campus timekeepers to adopt 4.2.6 as soon as it comes out, and have them encourage THEIR peers to do the same). -- 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] Syncing to nearby vs. faraway servers
On 6/15/09 2:38 PM, Rich wrote: > Is this sort of behaviour to be expected? Does this mean that the NTP > algorithm ought to be giving more weight to servers with shorter > delays? Or, perhaps, does it suggest that there might be something > wrong with the Stanford servers that is making them all cluster around > a time that is several milliseconds different from the rest of the > world? Keep in mind that the NTP protocol can't handle asymmetric round-trip delay. It's more likely that the faraway servers have asymmetric paths to Stanford, which would explain their offsets. (They are also more likely to have higher jitter.) If you're actually on the Stanford network, you may want to use one of the public NTP servers on the CalREN network, since those servers are close by and their paths are likely to be symmetric. michael ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Unruh wrote: > John Hasler writes: > >> Richard B. Gilbert writes: >>> Country pools were a good start and probably adequate for small >>> countries. Countries the size of the U.S. or the U.S.S.R. can't use a >>> country wide pool and have much hope of getting a nearby server. For the >>> U.S. I'd want a "New England pool", a "middle Atlantic pool" (New Jersey, >>> Pennsylvania, Delaware, Maryland, and Virgina), a Southern Atlantic Pool, >>> etc. This assumes that "net space" maps well to geographical space which >>> may not always be a good assumption. > >> My best servers are often on the coasts. I'm in Wisconsin. In any case >> country pools are quite adequate for 99% of users for whom anything better >> than +-0.5 seconds is good enough. > >>> If a request for a pool server could specify the requester's latitude and >>> longitude perhaps that information could be used to assign a nearby >>> server? > >> Seems like an unnecessary complication. Anyone who needs that sort of >> performance should be willing and able to select servers by hand. >> -- > > Or buy themselves a GPS time source. > I've done both! ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich Wales wrote: > Richard B. Gilbert wrote: > >> The "Delay" values for some of the servers you have configured >> are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > > This does suggest that even servers randomly picked from my own > country's pool (*.us.pool.ntp.org) might not be good choices. > > When 4.2.6 comes out, will the "pool" command with the "preempt" > option do a better job of weeding out pool servers that are far > away, and thus possibly of doubtful reliability? > Hi Rich. Long time (UCLA '82). The selection algorithm already does favor shorter delay servers, all other things being equal. The selection algorithm is actually pretty complex, but the delay is taken into account at one point. Actually, it happens even earlier, because the choice of sample from any given server is made based on the delay. So, of the potential 8 samples from any one server, the one with the smallest delay is taken. As far as the preempt keyword, it does what you want in theory. I haven't tried it in a while, but the last time I gave it a shot, I thought that it whittled down the list way too fast. YMMV. My personal vision is to have the NTP network be self-organizing and emergent. I am afraid there is a long way to go in that regard. Brian Utterback ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
> As for grandfather's two stratum-1 backup servers, here's the current > info on bigben.cac.washington.edu: > > ntpq> host > current host is bigben.cac.washington.edu > ntpq> peers > remote refid st t when poll reach delay offset jitter > == > *GPS_VME(0) .USNO. 0 l 9 16 377 0.000 -0.014 0.058 > 192.5.40.40 .INIT. 16 u - 1024 0 0.000 0.000 4000.00 > 204.34.198.40 .INIT. 16 u 26h 1024 0 0.000 0.000 4000.00 > ntpq> rl 0 > associd=0 status=0444 leap_none, sync_uhf_radio, 4 events, freq_mode, > version="ntpd 4@1.1161-r Tue Mar 23 22:34:33 UTC 2004 (19)", > processor="9000/800", system="HP-UX/B.11.11", leap=00, stratum=1, > precision=-18, rootdelay=0.000, rootdispersion=0.643, peer=25020, > refid=USNO, reftime=cde2500a.4f0dec40 Tue, Jun 16 2009 10:08:26.308, > poll=4, clock=cde2500d.8a678bfe Tue, Jun 16 2009 10:08:29.540, state=4, > offset=-0.028, frequency=-38.586, jitter=0.043, stability=0.001, > hostname="bigben", signature="md5WithRSAEncryption", flags=0x80001, > hostkey=3279293228, refresh=3454105890 > > I note that both grandfather.stanford.edu and bigben.cac.washington.edu > seem to be on good terms with their respective reference clocks, and > yet Stanford is seeing a significant offset w/r/t Washington right now. Another perspective on bigben.cac.washington.edu (some associations elided for brevity): C:\NTPb\bin>ntpq -p -crv ntp.davehart.net associd=0 status=0115 leap_none, sync_pps, 1 event, clock_sync, version="ntpd 4.2.5p...@1.1884-o Jun 16 6:43:12.67 (UTC-00:00) 2009 (1)", processor="x86", system="Windows", leap=00, stratum=1, precision=-19, rootdelay=0.000, rootdisp=0.458, refid=kPPS, reftime=cde26107.c6915af4 Tue, Jun 16 2009 18:20:55.775, clock=cde26116.70129ab2 Tue, Jun 16 2009 18:21:10.437, peer=21579, tc=4, mintc=3, offset=0.012, frequency=-22.794, sys_jitter=0.003, clk_jitter=0.003, clk_wander=0.000 remote refid st t when poll reach delay offset jitter == *GPS_NMEA(1) .kGPS. 0 l 15 16 3770.000 -0.034 0.004 oPPS(1) .kPPS. 0 l 15 16 3770.0000.012 0.003 -ntp3.isc.org204.152.187.43 2 u9 64 377 47.4290.203 0.128 -clock.via.net .GPS.1 u 47 128 377 45.2680.843 11.658 +usno.pa-x.dec.c .USNO. 1 u7 128 377 46.733 -0.435 1.508 -clepsydra.dec.c .GPS.1 u 27 128 377 45.0700.048 0.135 -montpelier.ilan .USNO. 1 u5 128 377 57.0992.170 0.722 -tick.ucla.edu .GPS.1 u 45 128 377 54.1660.892 16.096 #bigben.cac.wash .USNO. 1 u5 128 377 53.234 -12.807 0.436 -time-nw.nist.go .ACTS. 1 u 95 128 377 24.5472.266 0.290 My association with ntp3.isc.org is using interleaved mode, and so should be correcting for asymmetric delays. As you can see, bigben is on the order of 10ms off from the consensus, at least from ntp.davehart.net's perspective on a verizon business-class DSL. I had also considered that the offset could be due to asymmetric routing, but given the same ~10ms offset seen from Stanford, and that bigben's backup sources are .INIT., I'm guessing bigben's clock-winder has left the building. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Replying to Bill Unruh: > If the Stanford machines all cluster around a time server milliseconds > different from the rest of the world they are wrong. Stanford's stratum-2 servers currently appear to be syncing to grandfather.stanford.edu (171.64.7.87) -- a stratum-1 server which is located here on the Stanford campus and is syncing to its own TrueTime GPS clock: ntpq> host current host is grandfather.Stanford.EDU ntpq> peers remote refid st t when poll reach delay offset jitter == *TRUETIME(1) .GPS.0 l 50 64 3770.000 -0.985 1.829 +bigben.cac.wash .USNO. 1 u 546 1024 377 22.287 10.470 0.654 +clock.isc.org .GPS.1 u 537 1024 3775.4193.775 0.098 ntpq> rl 0 associd=0 status=0464 leap_none, sync_uhf_radio, 6 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=4.536, peer=28528, refid=GPS, reftime=cde24fb4.00436a6b Tue, Jun 16 2009 10:07:00.001, poll=10, clock=cde24fe8.c16630c8 Tue, Jun 16 2009 10:07:52.755, state=4, offset=-0.985, frequency=91.096, jitter=1.829, noise=2.957, stability=0.000, tai=0 As for grandfather's two stratum-1 backup servers, here's the current info on bigben.cac.washington.edu: ntpq> host current host is bigben.cac.washington.edu ntpq> peers remote refid st t when poll reach delay offset jitter == *GPS_VME(0) .USNO. 0 l9 16 3770.000 -0.014 0.058 192.5.40.40 .INIT. 16 u- 102400.0000.000 4000.00 204.34.198.40 .INIT. 16 u 26h 102400.0000.000 4000.00 ntpq> rl 0 associd=0 status=0444 leap_none, sync_uhf_radio, 4 events, freq_mode, version="ntpd 4@1.1161-r Tue Mar 23 22:34:33 UTC 2004 (19)", processor="9000/800", system="HP-UX/B.11.11", leap=00, stratum=1, precision=-18, rootdelay=0.000, rootdispersion=0.643, peer=25020, refid=USNO, reftime=cde2500a.4f0dec40 Tue, Jun 16 2009 10:08:26.308, poll=4, clock=cde2500d.8a678bfe Tue, Jun 16 2009 10:08:29.540, state=4, offset=-0.028, frequency=-38.586, jitter=0.043, stability=0.001, hostname="bigben", signature="md5WithRSAEncryption", flags=0x80001, hostkey=3279293228, refresh=3454105890 I note that both grandfather.stanford.edu and bigben.cac.washington.edu seem to be on good terms with their respective reference clocks, and yet Stanford is seeing a significant offset w/r/t Washington right now. I can't get any more info on clock.isc.org; it doesn't appear to be configured to permit outside queries. > There may be some problem with asymmetric delays to the Stanford > machines. Based on the above, it does look like there *could* be significant asymmetry between Stanford and the University of Washington. Or, there could be something amiss with the setup of Stanford's and/or Washington's stratum-1 servers and/or reference clocks. I don't work with the group managing Stanford's campus NTP service; I can try tracking them down and asking them questions, but I don't know what (if anything) I'll be able to find. As for my own paths to the Stanford campus NTP servers, my work desktop (100BASE-TX to the campus backbone) is currently getting delays of less than 1 msec to three campus stratum-2 servers: ntpq> host current host is localhost ntpq> peers remote refid st t when poll reach delay offset jitter == -liberation.rich 10.0.229.53 5 u 37 64 3766.582 -0.078 0.902 whodunit.richw. 10.0.229.114 4 u 173 256 3736.2470.576 7.396 -sandals.richw.o 10.0.229.53 5 u 176 256 376 27.820 -36.280 5.879 +Argus.Stanford. 171.64.7.87 2 u 30 1024 3770.864 -0.852 0.066 +caribou.Stanfor 171.64.7.87 2 u 869 1024 3770.748 -0.816 0.108 *dusk.Stanford.E 171.64.7.87 2 u 221 1024 3770.7813.065 0.159 -198.186.191.229 64.147.116.229 2 u 90 1024 377 18.8193.815 1.206 -14.1e.5546.stat 128.249.1.10 3 u 88 1024 377 48.1916.928 0.643 xntp1.sscgateway 136.159.2.9 3 u 792 1024 377 63.018 98.021 16.014 -bock130.dotsour 192.53.103.108 2 u 87 1024 377 165.5959.211 19.234 -cheddar.halon.o 193.0.0.228 2 u 33 1024 377 168.7418.314 4.664 ntpq> rl 0 associd=0 status=06f4 leap_none, sync_ntp, 15 events, freq_mode, version="ntpd 4.2@1.1520-o Wed May 13 21:05:42 UTC 2009 (1)", processor="i686", system="Linux/2.6.28-11-generic", leap=00, stratum=3, precision=-20, rootdelay=5.145, rootdispersion=72.180, peer=56461, refid=171.64.7.89, reftime=cde250e7.f1698f15 Tue, Jun 16 2009 10:12:07.943, poll=10, clock=cde251cb.ada3d08e Tu
Re: [ntp:questions] Syncing to nearby vs. faraway servers
John Hasler writes: >Richard B. Gilbert writes: >> Country pools were a good start and probably adequate for small >> countries. Countries the size of the U.S. or the U.S.S.R. can't use a >> country wide pool and have much hope of getting a nearby server. For the >> U.S. I'd want a "New England pool", a "middle Atlantic pool" (New Jersey, >> Pennsylvania, Delaware, Maryland, and Virgina), a Southern Atlantic Pool, >> etc. This assumes that "net space" maps well to geographical space which >> may not always be a good assumption. >My best servers are often on the coasts. I'm in Wisconsin. In any case >country pools are quite adequate for 99% of users for whom anything better >than +-0.5 seconds is good enough. >> If a request for a pool server could specify the requester's latitude and >> longitude perhaps that information could be used to assign a nearby >> server? >Seems like an unnecessary complication. Anyone who needs that sort of >performance should be willing and able to select servers by hand. >-- Or buy themselves a GPS time source. >John Hasler >j...@dhh.gt.org >Dancing Horse Hill >Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Richard B. Gilbert writes: > Country pools were a good start and probably adequate for small > countries. Countries the size of the U.S. or the U.S.S.R. can't use a > country wide pool and have much hope of getting a nearby server. For the > U.S. I'd want a "New England pool", a "middle Atlantic pool" (New Jersey, > Pennsylvania, Delaware, Maryland, and Virgina), a Southern Atlantic Pool, > etc. This assumes that "net space" maps well to geographical space which > may not always be a good assumption. My best servers are often on the coasts. I'm in Wisconsin. In any case country pools are quite adequate for 99% of users for whom anything better than +-0.5 seconds is good enough. > If a request for a pool server could specify the requester's latitude and > longitude perhaps that information could be used to assign a nearby > server? Seems like an unnecessary complication. Anyone who needs that sort of performance should be willing and able to select servers by hand. -- John Hasler j...@dhh.gt.org Dancing Horse Hill Elmwood, WI USA ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich Wales wrote: > Richard B. Gilbert wrote: > >> The "Delay" values for some of the servers you have configured >> are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > > This does suggest that even servers randomly picked from my own > country's pool (*.us.pool.ntp.org) might not be good choices. > > When 4.2.6 comes out, will the "pool" command with the "preempt" > option do a better job of weeding out pool servers that are far > away, and thus possibly of doubtful reliability? > I don't think that "reliability" is a good word choice here. A server may be perfectly reliable and yet be unusable due to long transmission delays. Suitability might be a better choice. Country pools were a good start and probably adequate for small countries. Countries the size of the U.S. or the U.S.S.R. can't use a country wide pool and have much hope of getting a nearby server. For the U.S. I'd want a "New England pool", a "middle Atlantic pool" (New Jersey, Pennsylvania, Delaware, Maryland, and Virgina), a Southern Atlantic Pool, etc. This assumes that "net space" maps well to geographical space which may not always be a good assumption. If a request for a pool server could specify the requester's latitude and longitude perhaps that information could be used to assign a nearby server? ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich writes:
>I'm running ntpd 4.2.4p4 on several Ubuntu 9.04 ("Jaunty") servers.
>I'm associated with Stanford University and have been depending
>primarily on Stanford's own pool of stratum-2 servers.
>Recently, in order to spread out my time base somewhat, I tried adding
>some outside servers (using the *.pool.ntp.org DNS names) to my NTP
>configurations. Since doing this, I've noticed that the nearby
>(Stanford) servers are uniformly "off" by several milliseconds, in
>comparison to more distant servers. Here, for example, is some output
>from the ntpq "peers" command (with host names turned off) on one of
>my servers:
> remote refid st t when poll reach delay
>offset jitter
>==
> 10.0.229.29 10.0.229.53 3 u 25 64 3760.109
>-3.955 0.130
>-10.0.229.114171.64.7.89 3 u 103 256 3776.058
>-5.277 3.545
>-10.0.229.117209.167.68.100 3 u 78 256 377 22.338
>-8.460 5.624
>+171.64.7.61 171.64.7.87 2 u 392 1024 3775.614
>-5.418 0.923
>+171.64.7.55 171.64.7.87 2 u 393 1024 3774.998
>-5.405 0.977
>-171.64.7.111171.64.7.87 2 u 394 1024 3775.598
>-5.499 1.000
>-207.150.167.80 209.51.161.238 2 u 387 1024 377 79.606
>6.888 1.485
>-72.36.170.170 132.163.4.1022 u 368 1024 377 51.702
>6.867 0.297
>-66.254.57.165 18.26.4.105 2 u 386 1024 377 95.627
>3.567 1.373
>*131.234.137.24 .DCF.1 u 449 1024 377 171.784
>0.923 0.978
>-89.16.178.36195.66.241.3 2 u 442 1024 377 157.082
>1.874 0.443
>(The 10.0.229.* servers are on my home LAN; the 171.64.7.* servers are
>at Stanford; and the others are from various places around the world
>and have much larger delays than the nearby servers.)
>I also see that the above machine is currently syncing to a server in
>Germany (delay = 171 msec) -- possibly because it's on stratum 1. (I
>submitted a separate posting questioning whether stratum-1 servers
>should really be in the pools, but that's a separate issue.)
>Is this sort of behaviour to be expected? Does this mean that the NTP
>algorithm ought to be giving more weight to servers with shorter
>delays? Or, perhaps, does it suggest that there might be something
>wrong with the Stanford servers that is making them all cluster around
>a time that is several milliseconds different from the rest of the
>world?
If the stanford machines all cluster around a time sever milliseconds
different from the rest of the world they are wrong. There may be some
problem with assymetric delays to the stanford machines.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich Wales wrote: > Richard B. Gilbert wrote: > > The "Delay" values for some of the servers you have configured > > are large enough to suggest that they are poor choices! > > Agreed. Please note, though, that I didn't explicitly choose > these particular servers -- they came from pools. > > This does suggest that even servers randomly picked from my own > country's pool (*.us.pool.ntp.org) might not be good choices. They're likely to be better choices than servers in the UK or Germany, as appear in your list -- you did say that was an experiment though. -- Ronan Flood ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich wrote: [] > Recently, in order to spread out my time base somewhat, I tried adding > some outside servers (using the *.pool.ntp.org DNS names) to my NTP > configurations. Since doing this, I've noticed that the nearby > (Stanford) servers are uniformly "off" by several milliseconds, in > comparison to more distant servers. Here, for example, is some output > from the ntpq "peers" command (with host names turned off) on one of > my servers: [] > I also see that the above machine is currently syncing to a server in > Germany (delay = 171 msec) -- possibly because it's on stratum 1. (I > submitted a separate posting questioning whether stratum-1 servers > should really be in the pools, but that's a separate issue.) > > Is this sort of behaviour to be expected? Does this mean that the NTP > algorithm ought to be giving more weight to servers with shorter > delays? Or, perhaps, does it suggest that there might be something > wrong with the Stanford servers that is making them all cluster around > a time that is several milliseconds different from the rest of the > world? > > Rich Wales Rich, Is it possible that your connection to one lot of servers is asymmetrical - in the sense of having more delay outbound than inbound or vice-versa? NTP cannot compensate for such asymmetry, and could cause the apparent offsets you have seen. You could also issue NTPQ commands against these remote servers. I have also seen NTP make what appear to be unusual choices for sync servers, and reported it here. As I now use my own stratum-1 servers and the "prefer" option, the problem has gone away. I was never completely convinced about such behaviour. Cheers, David ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Richard B. Gilbert wrote: > The "Delay" values for some of the servers you have configured > are large enough to suggest that they are poor choices! Agreed. Please note, though, that I didn't explicitly choose these particular servers -- they came from pools. This does suggest that even servers randomly picked from my own country's pool (*.us.pool.ntp.org) might not be good choices. When 4.2.6 comes out, will the "pool" command with the "preempt" option do a better job of weeding out pool servers that are far away, and thus possibly of doubtful reliability? -- Rich Wales / ri...@richw.org / richwa...@gmail.com 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] Syncing to nearby vs. faraway servers
On Mon, Jun 15, 2009 at 11:35 PM, Richard B. Gilbert wrote: > The best choices, other things being equal, are the servers with the > lowest round trip delays. As usual, though, all other things are not equal. Notice a number of the nearby servers have higher apparent jitter in the peers billboard snapshot. Look at individual associations using "ntpq -cas -p" to correlate peer to association ID then "ntpq -c 'rv ___'" filling in the blank with the association ID. Root dispersion plus dispersion from that output gives an estimate of maximum error for you from that source. Jitter (variability in apparent offset) is a killer. Low delay plus high jitter is not better than high delay plus low jitter. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Syncing to nearby vs. faraway servers
Rich wrote:
> I'm running ntpd 4.2.4p4 on several Ubuntu 9.04 ("Jaunty") servers.
> I'm associated with Stanford University and have been depending
> primarily on Stanford's own pool of stratum-2 servers.
>
> Recently, in order to spread out my time base somewhat, I tried adding
> some outside servers (using the *.pool.ntp.org DNS names) to my NTP
> configurations. Since doing this, I've noticed that the nearby
> (Stanford) servers are uniformly "off" by several milliseconds, in
> comparison to more distant servers. Here, for example, is some output
> from the ntpq "peers" command (with host names turned off) on one of
> my servers:
>
> remote refid st t when poll reach delay
> offset jitter
> ==
> 10.0.229.29 10.0.229.53 3 u 25 64 3760.109
> -3.955 0.130
> -10.0.229.114171.64.7.89 3 u 103 256 3776.058
> -5.277 3.545
> -10.0.229.117209.167.68.100 3 u 78 256 377 22.338
> -8.460 5.624
> +171.64.7.61 171.64.7.87 2 u 392 1024 3775.614
> -5.418 0.923
> +171.64.7.55 171.64.7.87 2 u 393 1024 3774.998
> -5.405 0.977
> -171.64.7.111171.64.7.87 2 u 394 1024 3775.598
> -5.499 1.000
> -207.150.167.80 209.51.161.238 2 u 387 1024 377 79.606
> 6.888 1.485
> -72.36.170.170 132.163.4.1022 u 368 1024 377 51.702
> 6.867 0.297
> -66.254.57.165 18.26.4.105 2 u 386 1024 377 95.627
> 3.567 1.373
> *131.234.137.24 .DCF.1 u 449 1024 377 171.784
> 0.923 0.978
> -89.16.178.36195.66.241.3 2 u 442 1024 377 157.082
> 1.874 0.443
>
> (The 10.0.229.* servers are on my home LAN; the 171.64.7.* servers are
> at Stanford; and the others are from various places around the world
> and have much larger delays than the nearby servers.)
>
> I also see that the above machine is currently syncing to a server in
> Germany (delay = 171 msec) -- possibly because it's on stratum 1. (I
> submitted a separate posting questioning whether stratum-1 servers
> should really be in the pools, but that's a separate issue.)
>
> Is this sort of behaviour to be expected? Does this mean that the NTP
> algorithm ought to be giving more weight to servers with shorter
> delays? Or, perhaps, does it suggest that there might be something
> wrong with the Stanford servers that is making them all cluster around
> a time that is several milliseconds different from the rest of the
> world?
>
> Rich Wales
> ri...@richw.org, richwa...@gmail.com
The "Delay" values for some of the servers you have configured are large
enough to suggest that they are poor choices! The potential error in
getting time from a distant server is limited to one half of the round
trip delay. It may and should be a lot better than that but it can't be
worse.
The best choices, other things being equal, are the servers with the
lowest round trip delays.
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Syncing to nearby vs. faraway servers
I'm running ntpd 4.2.4p4 on several Ubuntu 9.04 ("Jaunty") servers.
I'm associated with Stanford University and have been depending
primarily on Stanford's own pool of stratum-2 servers.
Recently, in order to spread out my time base somewhat, I tried adding
some outside servers (using the *.pool.ntp.org DNS names) to my NTP
configurations. Since doing this, I've noticed that the nearby
(Stanford) servers are uniformly "off" by several milliseconds, in
comparison to more distant servers. Here, for example, is some output
from the ntpq "peers" command (with host names turned off) on one of
my servers:
remote refid st t when poll reach delay
offset jitter
==
10.0.229.29 10.0.229.53 3 u 25 64 3760.109
-3.955 0.130
-10.0.229.114171.64.7.89 3 u 103 256 3776.058
-5.277 3.545
-10.0.229.117209.167.68.100 3 u 78 256 377 22.338
-8.460 5.624
+171.64.7.61 171.64.7.87 2 u 392 1024 3775.614
-5.418 0.923
+171.64.7.55 171.64.7.87 2 u 393 1024 3774.998
-5.405 0.977
-171.64.7.111171.64.7.87 2 u 394 1024 3775.598
-5.499 1.000
-207.150.167.80 209.51.161.238 2 u 387 1024 377 79.606
6.888 1.485
-72.36.170.170 132.163.4.1022 u 368 1024 377 51.702
6.867 0.297
-66.254.57.165 18.26.4.105 2 u 386 1024 377 95.627
3.567 1.373
*131.234.137.24 .DCF.1 u 449 1024 377 171.784
0.923 0.978
-89.16.178.36195.66.241.3 2 u 442 1024 377 157.082
1.874 0.443
(The 10.0.229.* servers are on my home LAN; the 171.64.7.* servers are
at Stanford; and the others are from various places around the world
and have much larger delays than the nearby servers.)
I also see that the above machine is currently syncing to a server in
Germany (delay = 171 msec) -- possibly because it's on stratum 1. (I
submitted a separate posting questioning whether stratum-1 servers
should really be in the pools, but that's a separate issue.)
Is this sort of behaviour to be expected? Does this mean that the NTP
algorithm ought to be giving more weight to servers with shorter
delays? Or, perhaps, does it suggest that there might be something
wrong with the Stanford servers that is making them all cluster around
a time that is several milliseconds different from the rest of the
world?
Rich Wales
ri...@richw.org, richwa...@gmail.com
___
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
