[ntp:questions] NTP v3 server, v4 client can't synch

Rob Neal hundoj at comcast.net
Wed Sep 9 20:45:14 UTC 2009



On Wed, 9 Sep 2009, Romain at ntp.org wrote:

> Greetings,
>
> I write with a concern from my day job, working on APM (application
> performance monitoring) devices for OPNET Technologies, Inc.  I'm
> attempting to help a customer who is using an NTP v3 server running
> under a VMware virtual machine.
 	Bad choice. Reconsider.
>  The APM device (FreeBSD) polls the
> server, but appears to give it no credence, prefering to wander off
> on its own until its own time is several minutes off.  Rebooting
> our device gives us a step correction with "ntpdate -b", so the v3
> server is apparently good enough for that purpose.
 	Minor nit: ntpdate is deprecated. Try to avoid it.
>
> As might be imagined, this is the sort of site where we have no
> choice except to try working with the existing plant.  There are
> about 10 APM devices running FreeBSD (ntpd 4.2.0-a) and none of
> them are able to peer with the designated server.  Yet the customer
> reports that they don't have trouble getting other NTP clients
> within their network to sync.
>
> The constraints imposed by the installation seem tight.  In
> addition to the NTPv3 service, the ntpq outputs below show high
> jitter, not surprising when a VM doesn't have any execution latency
> assurances.  The server reports stratum=7, which makes me wonder
> if the whole works are actually unsynchronized, but ntptrace times
> out while trying to discover more.
>
> - Continual, automatic step corrections are undersirable because they
>  will cause bogus measurements in the APM device.
  	-x on command line for ntpd, assuming you are willing
 	to wait ?? long for corrections.
>
> - Specifying NTP version 3 in the "server" line had no benefit.
>
> - Given that there's no synch with root, we're guessing
>  that attempting to peer the APM devices is probably futile.
>
> - Specifying a lower minpoll seems like it could magnify the effect
>  of the server jitter.
>
> Perhaps we want to clear out ntp.drift and set high minpoll/maxpoll?
> (E.g., minpoll 10 / maxpoll 14).
>
> Might the huff-'n-puff filter help negate the server jitter?
>
> Any other suggestions?
>
> Thanks!
>
> Sample ntpq outputs follow...
>
> ntpq> peers
>   remote           refid       st t when poll reach   delay   offset  jitter
> =============================================================================
> 172.20.18.68   aaa.bbb.ccc.ddd  7 u  844 1024   377   1.025  581084. 598.644
> *LOCAL(0)       LOCAL(0)        10 l   40   64   377   0.000    0.000   0.001
 	Oh, bad config. Two sources is evil. Do one, three or (best) 4+,
 	but not two.
 	And the LOCAL clock has hurt more folk than it has helped. If
 	you don't fully understand why it's there, lose it.
>
> ntpq> assoc
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>  1 9692   b014   yes   yes  none    reject   reachable   1
>  2 9693   9614   yes   yes  none  sys.peer   reachable   1
>
> ntpq> pstatus 9692
>
> status=b014 reach, conf, 1 event, event_reach,
> srcadr=172.20.16.33, srcport=123, dstadr=172.20.18.68,
> dstport=123, leap=00, stratum=7, precision=-6, rootdelay=31.250,
> rootdispersion=905.106, refid=aaa.bbb.ccc.ddd, reach=377, unreach=0,
> hmode=3, pmode=4, hpoll=10, ppoll=10, flash=00 ok, keyid=0, ttl=0,
> offset=581084.301, delay=1.025, dispersion=30.385, jitter=598.644,
> reftime=ce002d00.39e3722a Thu, Jul 9 2009 3:46:56.226,
> org=ce007490.f9e3722a Thu, Jul 9 2009 8:52:16.976,
> rec=ce00724b.e47048df Thu, Jul 9 2009 8:42:35.892,
> xmt=ce00724b.e42d1b9b Thu, Jul 9 2009 8:42:35.891,
> filtdelay=     1.03    1.00    0.99    1.40    1.25    0.86    1.39    1.29,
> filtoffset=  581084. 580485. 579932. 579333. 578734. 578134. 577550. 576967.,
> filtdisp=     15.63   30.99   46.33   61.72   77.08   92.44   107.80 123.1
 	root dispersion + jitter = unworthy. These numbers are awful.
>
> ntpq> pstatus 9693
> status=9614 reach, conf, sel_sys.peer, 1 event, event_reach,
> srcadr=LOCAL(0), srcport=123, dstadr=127.0.0.1, dstport=123, leap=00,
> stratum=10, precision=-20, rootdelay=0.000, rootdispersion=10.000,
> refid=LOCAL(0), reach=377, unreach=0, hmode=3, pmode=4, hpoll=6,
> ppoll=6, flash=00 ok, keyid=0, ttl=0, offset=0.000, delay=0.000,
> dispersion=0.917, jitter=0.001,
> reftime=ce0075ee.e3fcb8eb Thu, Jul 9 2009 8:58:06.890,
> org=ce0075ee.e3fcb8eb Thu, Jul 9 2009 8:58:06.890,
> rec=ce0075ee.e3fcde66 Thu, Jul 9 2009 8:58:06.890,
> xmt=ce0075ee.e3fc9370 Thu, Jul 9 2009 8:58:06.890,
> filtdelay=     0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
> filtoffset=    0.00    0.00    0.00    0.00    0.00    0.00    0.00    0.00,
> filtdisp=      0.00    0.95    1.89    2.84    3.83    4.79    5.75    6.72
 	Looks like a winner, compared to the other. So you get it as
 	syspeer. Not what you wanted, just what you asked for.
>
> It's not an apples-to-apples comparison, but here are a few
> ntpq outputs from an equivalent device running in our lab:
>
> ntpq> rv
> status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
> version="ntpd 4.2.0-a Tue Jan 15 23:21:10 UTC 2008 (1)",
> processor="amd64", system="FreeBSD/6.3-RELEASE", leap=00, stratum=3,
> precision=-20, rootdelay=12.202, rootdispersion=94.765, peer=23700,
> refid=10.21.1.21,
> reftime=ce51690f.a3bebb04  Tue, Sep  8 2009 16:36:47.639, poll=7,
> clock=ce516b6b.7f4501f0  Tue, Sep  8 2009 16:46:51.497, state=4,
> offset=-1.532, frequency=52.385, jitter=0.477, stability=0.060
>
> ntpq> peers
>     remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> *scout.fractal.n 204.152.184.72   2 u   90  128  377    0.257   -1.170   0.111
> LOCAL(0)        LOCAL(0)        10 l   32   64  377    0.000    0.000   0.001
>
> ntpq> as
> ind assID status  conf reach auth condition  last_event cnt
> ===========================================================
>  1 23700  b614   yes   yes  none  sys.peer   reachable  1
>  2 23701  9014   yes   yes  none    reject   reachable  1
>
> ntpq> pstatus 23700
> status=b614 reach, conf, sel_sys.peer, 1 event, event_reach,
> srcadr=scout.fractal.networkphysics.com, srcport=123, dstadr=10.22.4.16,
> dstport=123, leap=00, stratum=2, precision=-20, rootdelay=11.948,
> rootdispersion=75.531, refid=204.152.184.72, reach=377, unreach=0,
> hmode=3, pmode=4, hpoll=7, ppoll=7, flash=00 ok, keyid=0, ttl=0,
> offset=-1.170, delay=0.257, dispersion=8.670, jitter=0.114,
> reftime=ce516bdb.8e3ad18d  Tue, Sep  8 2009 16:48:43.555,
> org=ce516c15.a382a12f  Tue, Sep  8 2009 16:49:41.638,
> rec=ce516c15.a3d11774  Tue, Sep  8 2009 16:49:41.639,
> xmt=ce516c15.a3b7f3ea  Tue, Sep  8 2009 16:49:41.639,
> filtdelay=     0.35    0.28    0.27    0.34    0.27    0.28    0.26    0.30,
> filtoffset=   -1.02   -1.01   -1.03   -1.08   -1.10   -1.13   -1.17   -1.25,
> filtdisp=      0.00    1.95    3.90    5.82    7.73    9.68   11.61   13.52
>
> --
> Romain Kang         Neither KZSU 90.1 FM Radio nor Stanford University assume
> rkang at opnet.com             no responsibility for the content of this message.
> romain at kzsu.stanford.edu
>
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/questions
>



More information about the questions mailing list