Tony Whitmore wrote:
> Dr Adam J Trickett wrote:
>
>> At least one of the time sources is reporting an upstream server.
>>
>> When I restart ntpd is syncs okay, but it does not keep time with the
>> reference thereafter.
>>
>> Either ntpd isn't correctly configured, or as you suggest the upstream
>> ntpd is odd.
>>
Is this a 64 bitter?
There's a known problem with the x86_64 package in RHEL4 U2 - see:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=158541
There's a link to an updated .src.rpm in that bug posting. (Or you can
download a prebuilt rpm:
http://tmp.askask.com/2006/01/ntp-4.2.0.a.20050816-10.x86_64.rpm
ntp-4.2.0.a.20050816-10.x86_64.rpm (no warranty, etc etc).
HtH,
jfk
>
> If it's a Windows NTP server, then it's seriously non-RFC compliant.
> The NTP server included on Windows servers (certainly Windows 2000
> servers) breaks in several ways the specification for the NTP protocol
> as defined in RFC 1305 at http://www.faqs.org/rfcs/rfc1305.html. (The
> NTP client incorporated with Microsoft Windows XP is also
> non-RFC-compliant.)
>
> They also report as stratum 2 servers by default, rather than
> calculating the stratum from the upstream server. Also, an RFC-compliant
> time server will drop to a low stratum (16) if it looses its upstream
> time source for more than 24 hours. Windows time servers don't do this.
> Of course, Windows clients are quite happy to use this unsynchronised,
> inaccurate time server as a time source. However, the NTP client
> implementation on Linux and BSD follows the RFC and rejects the server
> as inaccurate. So you end up explaining to Windows server admins why
> their desktops will sync with the Windows NTP server and the Linux boxes
> won't.
>
> I have had some joy using the Windows binary of the reference NTP
> implementation on Windows 2000 servers. Things did seem to have improved
> a bit with Windows 2003 Server, but I didn't have time to investigate
> too thoroughly before I left.
>
> HTH,
>
> Tony
>
>
