On Wed, 18 Aug 1999, Ken Hornstein wrote:

> >IMO, what's the hurry? The nanotime stuff, which is disabled in the
> >package, is fairly forward-looking. Little benefit would be obtained
> >for the majority of hardware available today. (Think V.90!)
> 
> I'm not sure I can agree with that.  The use of process cycle counters
> seems like it will benefit timekeeping on a number of architectures in
> use today.

What about ethernet round trip times? If you really need all your
machines synced to within 1uS of each other, you would practically
need to put a reference clock on each of them. Some posters on
comp.protocols.time.ntp do exactly that, but to claim immediate
practical benefit for the average user would be... deceptive.

> >the ntp4.x.x distribution is still in pre-release. One recent snapshot
> >had a wicked bug which caused certain clocks to diverge. There's still
> >a similar problem with WinNT boxes, but that may turn out to be very
> >specific to WinNT, or perhaps to the compiler used.
> 
> I agree with that; I think that definately we should wait until ntp4
> stabilizies a bit more.  However, I don't think putting in the nanokernel
> stuff now affects that.

Actually, it currently works great for my minimal needs, and my sense
of it is that there's not going to be any major changes before the
release. Certainly no rethinking of the interface or the protocol.

If you, or anyone, is willing to do the work, I don't mean to talk you
out of it. The benefits would be more strategic than immediate: the
existing binaries break once, but then everything's set for a long time.

"Time freaking" has it's own rewards. My rootshell on one machine has
a couple of 1-key shortcuts for each host, '/usr/pkg/bin/ntpq -c rl
host1; /usr/pkg/bin/ntpq -c pe host1' and so on. My cow-orkers try to
guess what I'm doing, staring at all those numbers, day after day. I
actually caught a bug that way, seeing the state change just as the
clock went nuts. Most people don't have the patience.