NTP Stratum

Chuck Swiger cswiger at mac.com
Tue Feb 9 00:38:48 UTC 2010


On Feb 8, 2010, at 6:16 AM, DAve wrote:
> I am syncing with three server from N.us.pool.ntp.org. I have no fudge
> configured.
> 
> ]# ntpq -c peers
>     remote           refid      st t when poll reach   delay   offset
> jitter
> ==============================================================================
> ns-01.tls.net   .INIT.          16 u    - 1024    0    0.000    0.000
> 4000.00
> +www.broadbandja 66.250.45.2      3 u  510 1024  377   61.944    3.528
> 0.230
> *point2.adamants 128.138.140.44   2 u  447 1024  377   59.360    0.863
> 0.154
> +66.36.239.104   69.64.37.141     3 u  507 1024  377   28.763    2.623
> 1.182
> 
> I am pretty sure I am just reading the man pages incorrectly, but then
> others things seem confusing as well.

A stratum-0 timesource is a reference clock like a GPS signal, atomic clock, or other very-high-quality timesource.  A computer running ntpd can sync time to such a device, and will thus be a stratum-1 timeserver.  Seeing NTP packets claiming to be stratum-0 is a sure indication that the ntpd thinks it is not properly synchronized, and NTP clients should ignore this timesource as a consequence.  See:

  http://www.ntp.org/ntpfaq/NTP-s-algo.htm#Q-ALGO-BASIC-STRATUM

"The stratum is a measure for synchronization distance.  Opposed to jitter or delay the stratum is a more static measure.  Basically (and from the perspective from a client) it is the number of servers to a reference clock.  So a reference clock itself appears at stratum 0, while the closest servers are at stratum 1.  On the network there is no valid NTP message with stratum 0."

[ ... ]
> I vote for higher, I have no fudge configured and my servers are
> claiming to be stratum 0 when I check them from outside. But!! Never
> trusting my observations until checking again, I see when I tested that
> my clocks were off. So if I cannot sync, my server continues to answer
> time queries but claims to be stratum 0.
> 
> I am thinking I am getting closer to grasping this.

That's correct.  If you run something like:

# ntpq -pc rv localhost
assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.4p5-a Tue Jan 12 18:52:12 EST 2010 (1)",
processor="i386", system="FreeBSD/6.4-STABLE", leap=00, stratum=2,
precision=-19, rootdelay=33.115, rootdispersion=28.426, peer=51948,
refid=18.26.4.105,
reftime=cf1b25fa.21d555c1  Mon, Feb  8 2010 19:08:26.132, poll=9,
clock=cf1b2a9f.c570e0a6  Mon, Feb  8 2010 19:28:15.771, state=4,
offset=-0.042, frequency=19.313, jitter=1.902, noise=0.625,
stability=0.001, tai=0
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+ntp.pbx.org     192.5.41.40      2 u  477  512  377   30.744    1.763   0.702
*bonehed.lcs.mit .GPS.            1 u  165  512  377   33.115   -0.495   0.157
-hickory.cc.colu 128.59.39.48     2 u  482  512  377   30.943    3.618   0.468
+time1.apple.com 17.72.133.55     2 u  465  512  377   54.572    1.374   8.022
 rrcs-24-103-228 18.26.4.105      2 u  505  512  377   34.623  -11.983   1.139
 rrcs-24-103-228 .INIT.          16 u    -  512    0    0.000    0.000   0.000

...pay attention to the status in the first line, which in the above case reads "sync_ntp".  I bet you're getting sync_unspec for your status.

Regards,
-- 
-Chuck




More information about the freebsd-questions mailing list