On 12/05/2010 21:55, David Woolley wrote:
Adrian Marsh wrote:
The main windows server is set to clock from time.nist.gov, and I'm
fighting to get the linux clients to sync from my internal server.
Windows clients seem ok (I know thats done via AD).
w32time needs a lot of tweaking to make it NTP compliant. I'm not sure
if all the tweaks are available in the Win2003 version. It is never as
good as running the ntpd reference implementation on Windows, and
running that on Unix or Linux is even better.
time.nist.gov is overloaded and unlikely to have an optimum network path
to you.
This was all working last week, except one client who insisted that
the offset was off by about 300 seconds. That machine was so bad we've
been in touch with Dell to look at the hardware.
However today, the main server needed a reboot, and since then I can't
get any of the linux clients to agree to sync to the main server (no *
against the peers listing).
You need to use ntpq rv to find out the status of the server and why it
is being rejected (use it with the association ids from ntpq assoc).
However, w32time clients do not reject servers with huge root
dispersions, resulting from the server being unsynchronised for a long
time.
As others have said, you should not have a local clock configured. It
should, however, only be used as a last resort.
Hi David,
Thanks for that. magically overnight all the servers have started
trusting the main server again. I'm wondering if, because of the
reboot, that the w2003 server hadn't yet synced to time.nist.gov, and so
maybe the clients knew not to "trust" it yet? It was several hours after
the reboot that I'd checked... Pure guessing there.
I'll hunt for a better source locally, and I'll remove the LOCAL from
non-servers.
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
