[ntp:questions] WARNING: someone's faking a leap second tonight

Martin Burnicki martin.burnicki at meinberg.de
Sun Aug 5 10:03:25 UTC 2012


Nathan Stratton Treadway wrote:

> date -u; ntpq -c "rv 0 leap,stratum,refid" name1.glorb.com

The command above doesn't report the version of the NTP daemon running on
that system.

date -u; /usr/sbin/ntpq -p -c rv name1.glorb.com
So 5. Aug 09:52:26 UTC 2012
     remote      refid    st t when poll reach   delay   offset  jitter
=======================================================================
-navobs1.oar.net .GPS.     1 u  108  256  377   11.545   -5.508   0.118
+clock.nyc.he.ne .CDMA.    1 u  196  256  377   18.289   -0.053   0.062
*truechimer.cite .PPS.     1 u  153  256  377   14.664    0.049   0.271
-time-b.nist.gov .ACTS.    1 u  719  256  254   27.975    4.316   0.089
-utcnist2.colora .ACTS.    1 u  125  256  377   36.595    0.137   0.039
-navobs1.wustl.e .GPS.     1 u  227  256  377   19.129   -0.140   0.075
-bonehed.lcs.mit .PPS.     1 u  205  256  377   26.380   -3.559   0.115
+navobs1.gatech. .GPS.     1 u  131  256  377   27.583   -0.031   0.128
-50-77-217-185-s .ACTS.    1 u   43  256  277   34.933   -3.199   1.403
-andromeda.cs.pu .CDMA.    1 u  122  256  377   12.729   -2.859   0.138
-nist.netservice .ACTS.    1 u  193  256  377    7.332    3.041   0.081
+ben.cs.wisc.edu .GPS.     1 u  235  256  377   19.632   -0.024   0.067
-rackety.udel.ed .PPS.     1 u  178  256  377   21.960   -2.131   0.035
x216.119.63.113  .ACTS.    1 u  181  256  377   48.526   14.320   0.088

associd=0 status=46f4 leap_add_sec, sync_ntp, 15 events, freq_mode,
version="ntpd 4.2.4p8 at 1.1612-o Wed Nov 24 19:02:25 UTC 2010 (1)",
processor="i686", system="Linux/2.6.32-131.6.1.el6.i686", leap=01,
stratum=2, precision=-20, rootdelay=14.664, rootdispersion=20.099,
peer=23785, refid=128.174.38.133,
reftime=d3c8bd40.03e02317  Sun, Aug  5 2012 11:37:04.015, poll=8,
clock=d3c8c0dc.88fe46f6  Sun, Aug  5 2012 11:52:28.535, state=4,
offset=-0.034, frequency=-356.152, jitter=0.263, noise=0.133,
stability=0.005, tai=0

So this is 4.2.4p8 which (if I remember correctly) accepts an incoming leap
warning even if only a single upstream server from the group of "survivors"
of the clustering algorithm provides it.

A quick inspection of the upstream servers shows indeed that only one of
them is providing the leap warning, namely truechimer.cites.illinois.edu

A 4.2.6 daemon would require a majority of the survivors to provide the leap
warning before it accepted it, so at least this server should not have the
eraaneous leat bit set if it were running 4.2.6.

If I remember correctly then cases like this where the reason why the
requirement of a majority was introduced after 4.2.4.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list