Re: [ Re: NTP dumps Linux, film at 11. [Fwd/FYI]]

Ulrich Windl (
Tue, 1 Dec 1998 08:29:39 +0100

On 1 Dec 98, at 2:12, Hubert Mantel wrote:

> Hi,
> na, waer das nix fuer Euch?

[Your message forwarded to me]

> ;-)
> ----- Forwarded message from Linus Torvalds <> -----
> Date: Mon, 30 Nov 1998 10:20:12 -0800 (PST)
> From: Linus Torvalds <>
> To: Kris Karas <>
> Cc:
> Subject: Re: NTP dumps Linux, film at 11. [Fwd/FYI]
> On Mon, 30 Nov 1998, Linus Torvalds wrote:
> >
> > What we need is simply some Linux person who knows and cares about NTP,
> > nothing more. It's unrealistic to assume that BSD people could maintain
> > ntpd with Linux support without anybody in the Linux camp being willing to
> > stand up for the Linux part.
> Btw, just in case people worry: don't worry too much. I use ntpd every
> day, and it works beautifully. But I know that at least early 2.1.x SMP
> kernels had horribly problems with ntpd - losing synchronization
> completely several times a day, and not ever really getting truly good
> time.

"ntpd" is a part from NTPv4 which is not yet defined. xntp4 is in an
alpha stage, and I don't understand why people complain so much about
it not working. Dave Mills and some Paul from the BSD camp are very
excited with their new nanosecond kernel resolution, but they don't
have a clever idea how to extend the old kernel interface in a
compatible way. There's also a new Internet draft for a PPS API.
It'll need some time until things get stable.

And I think that people shoot themselves in their own foot when
complaining about some alpha code not working for Linux without
having made some contribution to that code. As a natural reaction the
maintainer wants to get rid of the complaints.

Incompatibilities between libc5 and libc6 add another complexity. For
historical reasons Linux uses one syscall (adjtimex) where the other
systems seem to use three (adjtime, net_adjtime, ntp_gettime). This
makes the autoconf stuff complicated.

I myself have not yet tried xntp4, because I know it needs time and
fixes, and I currently don't have the capacity (time and disk).

> I suspect the same is true of 2.0.x SMP - the problem was due to simply
> horribly bad timer tick latencies under any kind of load, due to both
> timer interrupts and the gettimeofday() functions using the single kernel
> lock. Any heavy kernel activity just killed it.

It would be a big help to get most of the POSIX.4 functionality (the
clock functions, struct timespec) in the kernel.

> The point still holds: in order to solidly support NTP in a reasonable
> fashion we need to have a ntp maintainer that is responsive and actively
> works on problems and is recognized as _the_ maintainer. But that doesn't
> mean that the current stuff is a complete disaster, it just means that I
> fully understand why some NTP people don't like the Linux situation.

Right: If you use a statically linked version of xntpd3-5.93 with
libc5 it is stable as rock, but you don't get the fractional
microseconds. (In reality clocks and timezones are frequently off by

I could try to maintain NTP kernel support, but I won't support any
alpha code that changes twice a week. NTP code needs a rewrite, and
so does all the Linux stuff in xntp. I don't have the right hardware
at home to test all that stuff, and the hardware we have here is not
best to be carried in a pocket.

Ulrich Windl

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at