Messages in this thread | | | From | "Ulrich Windl" <> | Date | Tue, 1 Dec 1998 08:29:39 +0100 | Subject | Re: [: Re: NTP dumps Linux, film at 11. [Fwd/FYI]] |
| |
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 <torvalds@transmeta.com> ----- > > Date: Mon, 30 Nov 1998 10:20:12 -0800 (PST) > From: Linus Torvalds <torvalds@transmeta.com> > To: Kris Karas <ktk@ktk.bidmc.harvard.edu> > Cc: linux-kernel@vger.rutgers.edu > 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 hours).
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.
Regards, Ulrich Windl
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |