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" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> > 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
