[ntp:questions] Re: two ntp servers

rancid moth rancidmoth at yahoo.com
Wed Feb 22 03:27:45 UTC 2006


hello Jed,

thanks for the advice.  I have opted to strip it all back and start again. 
I did as you suggested and left on the server line in the config.  and I 
doubled checked every step.  I also opted for a completely different 
upstream server.  this time the ntpq -p status seems more logical (i.e. 
there is actually numbers in it rather than zeros).  I also watched the 
packets on the interface via tcpdump -ieth2 -p udp and ensured that this 
upstream server was spitting back data that was reaching the interface.  I 
then made both servers have the same config and upstream data and va la! 
they are now both exactly on the same time.  I am now going through the 
config to see if there is anyline in it that breaks this.

thanks to all for the tips, especially the ntpq -p

cheers
moth

"Jed Clear" <clear at alum.mit.edu> wrote in message 
news:43FA830D.B319B3D0 at alum.mit.edu...
> rancid moth wrote:
>>
>> hello john
>>
>> no it seems to definitely be reaching them.  i have checked using the
>> dmpeers command.  also running the ntpq -p i get the exact same thing as
>> what is on the other box.  also note that in my trials i have set a 
>> machines
>> time from off the other machine and made them perfectly in synch.  when i
>> then take that machine and point it to the upstream server it then drifts
>> until it is three minutes ahead.  i just dont get it.  odd dont you 
>> think?
>
> Could be something misconfigured in your ntp.conf that prevents ntp from
> actually setting the local clock, so it continues to drift.  Auth can be
> tricky.  Also I recall posts of an option that seems to have changed 
> logical
> sense after a certain older ntpd version, but examples might not be 
> updated.
>
> I would start with a very simple ntp.conf:
>
> server ntp.yourISP.com
>
> and *nothing* else.  If your ISP doesn't offer NTP (you might have to ask 
> their
> support desk), go pick an open stratum 2 off the wicki.  Don't use the 
> pool
> initially as your two servers could (should) get different servers for the 
> same
> name.  If that works, add a bit of your current ntp.conf back in at a time 
> until
> it breaks.  From what I've read here, you shouldn't be using minpoll and 
> maxpoll
> options at all.
>
> If you find you need to come back for more advice, those more 
> knowledgeable than
> myself could probably help more if they knew what version of ntpd you're 
> running
> and what's in your ntp.conf.
>
> HTH,
>
> -Jed
>
>>
>> "John Pettitt" <jpp at cloudview.com> wrote in message
>> news:43F4FDCA.3070402 at cloudview.com...
>> > rancid moth wrote:
>> >> hello,
>> >>
>> >> not being very familiar with the ntp protocol, and currently 
>> >> introducing
>> >> myself to it properly (i.e. have always used though never dug deeply 
>> >> into
>> >> it), i have established two ntp services on two different Linux 
>> >> machines.
>> >> Both ntp servers are pointing to the _same_ upstream server.  There is 
>> >> a
>> >> four minute difference in time on the machines.  Lets call them 
>> >> machine A
>> >> and B.  initially i established them to the same time, by synching B's
>> >> time
>> >> from A which itself was synched from the upstream internet ntp server.
>> >> If i
>> >> then modify B's config to also synch from the same upstream source, B,
>> >> given
>> >> enough time, will drift 4 minutes ahead of A.  Can someone please 
>> >> point
>> >> me
>> >> to an introductory explanation as to why/how this can occur.
>> >>
>> >> cheers
>> >> moth
>> >>
>> >>
>> >
>> > Basically your setup isn't working for some reason - if you do 
>> > "ntpq -p"
>> > on both boxes you'll
>> > probably see that one or both of them are not actually talking to the
>> > upstream.    As a general rule
>> > you need at least four upstream servers for stability (see
>> > www.pool.ntp.org for how to get more
>> > servers).  It's probably a good idea to peer the two local servers and
>> > then point them at diverse
>> > (overlapping is ok) groups of upstream servers as this will give to a 
>> > very
>> > robust setup.
>> >
>> > If I had to guess I'd say that a firewall somplace is blocking the ntp
>> > packets.
>> >
>> > John 





More information about the questions mailing list