[ale] NTPD issues

Michael H. Warfield mhw at wittsend.com
Wed Mar 9 07:32:47 EST 2005


On Tue, 2005-03-08 at 22:19 -0500, Ryan Fish wrote:
> H.A.,

> I have done this several times but the same issue continues to occur.
> Within a minute of my starting ntpd again the following is shown:

	You don't say what distro or kernel version but I had a similar problem
with Fedora Core 3 and some of the 2.6.9 kernels.  There seems to have
been some problem with APCI support that was causing excessive jitter
which would then lead ntpd to loose sync.  I had to set the following on
the kernel boot options in grub in order to stabilize things:

	apm=off acpi=off

	Seems to have settled down with the 2.6.10 kernels, so I guess they
fixed what ever they broke.

	There were some kernel threads several months ago about "runaway
clocks" or some such which is what lead me to try that.  Wasn't
happening on all my machines, though, just a couple.  Might be worth a
shot.

	Mike

> 
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u   49   64    1   21.579  -1011.5
> 0.008
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   46   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u   54   64    1   25.657  -660.93
> 0.008
>  rubidium.broad. .GPS.            1 u   47   64    1   38.042  -1414.5
> 0.008
>  rackety.udel.ed PPS(0)           2 u   47   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u   55   64    1   21.579  -1011.5
> 0.008
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   52   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u   60   64    1   25.657  -660.93
> 0.008
>  rubidium.broad. .GPS.            1 u   53   64    1   38.042  -1414.5
> 0.008
>  rackety.udel.ed PPS(0)           2 u   53   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u   59   64    1   21.579  -1011.5
> 0.008
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   56   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u    1   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u   57   64    1   38.042  -1414.5
> 0.008
>  rackety.udel.ed PPS(0)           2 u   57   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u   62   64    1   21.579  -1011.5
> 0.008
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   59   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u    4   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u   60   64    1   38.042  -1414.5
> 0.008
>  rackety.udel.ed PPS(0)           2 u   60   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u   64   64    1   21.579  -1011.5
> 0.008
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   61   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u    6   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u   62   64    1   38.042  -1414.5
> 0.008
>  rackety.udel.ed PPS(0)           2 u   62   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u    -   64    3   21.591  -7611.7
> 6600.17
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   63   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u    8   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u    1   64    3   27.784  -7609.6
> 6195.16
>  rackety.udel.ed PPS(0)           2 u   64   64    1   35.214  -1416.1
> 0.008
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u    1   64    3   21.591  -7611.7
> 6600.17
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u   64   64    1    2.137  -1689.9
> 0.008
>  louie.udel.edu  128.4.40.20      2 u    9   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u    2   64    3   27.784  -7609.6
> 6195.16
>  rackety.udel.ed PPS(0)           2 u    -   64    3   23.654  -7680.4
> 6264.37
> [root at server ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  hickory.cc.colu navobs1.wustl.e  2 u    3   64    3   21.591  -7611.7
> 6600.17
>  ns1.usg.edu     ntp0.mcs.anl.go  2 u    -   64    3    3.017  -7679.5
> 5989.62
>  louie.udel.edu  128.4.40.20      2 u   11   64    3   24.961  -7361.0
> 6700.12
>  rubidium.broad. .GPS.            1 u    4   64    3   27.784  -7609.6
> 6195.16
>  rackety.udel.ed PPS(0)           2 u    2   64    3   23.654  -7680.4
> 6264.37
> 
> 
> As can be seen above, the offset goes nuts instantly and the jitter follows
> very soon after...
> 
> I have the exact same ntp.conf file (less one ntp server) setup on another
> server in the same network (just set it up within the past hour) and it is
> working fine:
> 
> [root at anotherserver ntp]# ntpq -p
>      remote           refid      st t when poll reach   delay   offset
> jitter
> ============================================================================
> ==
>  LOCAL(0)        LOCAL(0)        10 l   24   64  377    0.000    0.000
> 0.004
> +hickory.cc.colu navobs1.wustl.e  2 u   30   64  377   21.855   35.685
> 1.837
> +ns1.usg.edu     ntp0.mcs.anl.go  2 u   17   64  377    2.461   37.043
> 1.860
> -louie.udel.edu  128.4.40.20      2 u   37   64  377   24.288    8.106
> 2.082
> *rubidium.broad. .GPS.            1 u   21   64  377   29.630   36.062
> 1.768
> 
> This just makes absolutely no sense to me...
> 
> Thanks again.
> -Ryan
> 
> 
> ----- Original Message ----- 
> From: "H. A. Story" <adrin at bellsouth.net>
> To: "Ryan Fish" <FishR at bellsouth.net>
> Sent: Tuesday, March 08, 2005 9:59 PM
> Subject: Re: [ale] NTPD issues
> 
> 
> > Okay
> >
> > Stop ntpd
> >
> > run ntpdate  from the command line.   ntpdate (ntp server)
> >
> > This will run and display messages as it runs.  I don't think you can
> > run this while ntpd is running.  You will actually get an error message
> > stating this.
> >
> >
> >
> > Ryan Fish wrote:
> > > I am using the same NTP servers on a box I have running here at home
> without
> > > any trouble.  This box has a dynamic IP assigned by BS on their kooky
> > > schedule...
> > >
> > > Why then would I have the same result with different NTP servers just
> added
> > > today?
> > >
> > > Does it matter if the server in question is able to resolve the NTP
> server
> > > addresses but NOT ping them successfully?  I can ping all the same NTP
> > > servers from other servers in the same network and from my home boxes.
> > > Since I am also able to successfully run NTPD from those same boxes I am
> > > leaning towards this being some sort of a network connectivity issue
> which I
> > > will need to figure out how to cure.  Make sense?
> > >
> > > Anyway, keep the ideas coming!
> > >
> > > Thanks again.
> > > -Ryan
> > >
> > >
> > > ----- Original Message ----- 
> > > From: "H. A. Story" <adrin at bellsouth.net>
> > > To: <FishR at bellsouth.net>; "Atlanta Linux Enthusiasts" <ale at ale.org>
> > > Sent: Tuesday, March 08, 2005 9:38 PM
> > > Subject: Re: [ale] NTPD issues
> > >
> > >
> > >
> > >>Hi,
> > >>Looks like a problem I had.  Some ntp servers will start rejecting you
> > >>if you connect to many times during a period, to fix this I just made a
> > >>script that only runs once a day to adjust the clock. This also takes
> > >>care of the jitter problem.
> > >>
> > >>Keep in mind it may not be all you if you are on a dynamic IP.
> > >>
> > >>
> > >>Ryan Fish wrote:
> > >>
> > >>>I have been successfully using ntpd on a RHEL3 ES server for roughly
> 1.5
> > >
> > > months now.  For some yet unknown reason the service just stopped
> working
> > > properly yesterday.  By this, I mean the service will run but will not
> > > actually connect to any NTP server I list in ntp.conf.
> > >
> > >>>ntpq -p returns the following:
> > >>>
> > >>>     remote           refid      st t when poll reach   delay   offset
> > >
> > > jitter
> > >
> > >
> ============================================================================
> > > ==
> > >
> > >>>*LOCAL(0)        LOCAL(0)        10 l    6   64  377    0.000    0.000
> > >
> > > 0.008
> > >
> > >>> hickory.cc.colu navobs1.wustl.e  2 u   13   64  377   22.013  -129454
> > >
> > > 4630.18
> > >
> > >>> ns1.usg.edu     ntp0.mcs.anl.go  2 u   37   64  377    2.586  -129254
> > >
> > > 6320.01
> > >
> > >>> louie.udel.edu  128.4.40.20      2 u   22   64  377   47.435  -129373
> > >
> > > 5099.01
> > >
> > >>> rubidium.broad. .GPS.            1 u   46   64  377   38.199  -129208
> > >
> > > 7104.82
> > >
> > >>>
> > >>>ntpq -d followed by assoc returns the following even after waiting a
> > >
> > > couple hours:
> > >
> > >>>ind assID status  conf reach auth condition  last_event cnt
> > >>>===========================================================
> > >>>  1 59084  9614   yes   yes  none  sys.peer   reachable  1
> > >>>  2 59085  9014   yes   yes  none    reject   reachable  1
> > >>>  3 59086  9014   yes   yes  none    reject   reachable  1
> > >>>  4 59087  9014   yes   yes  none    reject   reachable  1
> > >>>  5 59088  9014   yes   yes  none    reject   reachable  1
> > >>>
> > >>>I have stopped, restarted and added more NTP servers but the service
> > >
> > > never actually starts working as it has and should.
> > >
> > >>>Any ideas???
> > >>>
> > >>>TIA
> > >>>- Ryan
> > >>>
> > >>>
> > >>>_______________________________________________
> > >>>Ale mailing list
> > >>>Ale at ale.org
> > >>>http://www.ale.org/mailman/listinfo/ale
> > >>
> > >>
> > >
> >
> >
> 
> 
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://www.ale.org/mailman/listinfo/ale
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw at WittsEnd.com  
  /\/\|=mhw=|\/\/       |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: This is a digitally signed message part




More information about the Ale mailing list