This is Has-anyone-made-any-progress-with-ntp-since-May-18-patchlevel-13? in view mode; [Up]
Date: Sun 01-Aug-1989 20:45:54 From: Unknown Subject: Has anyone made any progress with ntp since May 18/patchlevel 13? The README file says it "doesn't work very well on a NeXT." -=EPS=- (For those of you that don't know, NTP is Network Time Protocol; you use it to synchronize clocks to an accurate reference. This is rather important in certain distributed applications.) >From: louie@trantor.umd.edu (Louis A. Mamakos)
Date: Sun 02-Aug-1989 04:15:14 From: Unknown Subject: Re: Has anyone made any progress with ntp since May 18/patchlevel 13? In article <356@wet.UUCP> epsilon@wet.UUCP (Eric P. Scott) writes: >The README file says it "doesn't work very well on a NeXT." > > -=EPS=- Actually, that fact that ntp can run at all is a large improvement. The ntp code (which is very portable to most BSD-like systems) croaked the machine under 0.8. It would completely and utterly hung the system. I submitted a bug report, and waited "until the next release." I had very high hopes for 0.9; but there is still a fundamental bit of bogosity on 0.9; the kernel, trying to be "helpful", resets the system time from the clock/calendar in the machine. Well, this completely hoses ntp which attempts to compute and compensate for the intrisitic drift of the system's clock. So now I wait, hoping that the kernel will be fixed and working in the 1.0 release of the software. It's a real shame; I intended to do most of the development and work on the UNIX NTP port on the NeXT machine. It has a higher resolution clock than the MicroVAX-II does. Wouldn't you like to keep your NeXT's clock synchronized within 5-10 milliseconds of the correct time? There's also the opportunity to refine the system clock by modifing the kernel's code that keeps the clock. Many of the algorithms used by NTP are much better implemented in the kernel rather than in user code. But of course, there's the old source issued that rears its ugly head again. I suppose that the OS development projects will continue to be done on a grundgy MicroVAX-II running 4.3-tahoe or 4.4BSD, rather than the NeXT machine on my desk. What a shame. Offer to NeXT: make a fixed kernel available for testing, and I'll test it for you! I want this stuff working *for sure* by the 1.0 release. Finding and fixing a bug every 6 months isn't the way to do things. Make intermediate versions available for testing at our own risk; wouldn't you like some feedback on your changes and corrections? Sorry for the little bits of flame that seem to make their way into this note; after banging your head against the wall for a while, you get real sensitive over many of these issues. Louis Mamakos keeper of UNIX NTP Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming >From: edwardm@hpcuhc.HP.COM (Edward McClanahan)
These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.