Subject: Re: Problem with ntpd in recent months?
To: Matthias Drochner <M.Drochner@fz-juelich.de>
From: Frederick Bruckman <fredb@immanent.net>
List: current-users
Date: 06/15/2004 16:42:04
On Tue, 15 Jun 2004, Matthias Drochner wrote:

> fredb@immanent.net said:
> > > So we'll
> > > have to maintain our local fixes for a while.
> > I'll try to keep up, so that the next snapshot may hopefully build and
> > run on NetBSD.
>
> So you are working on getting the scopeid/zone fixes into the ntp tree?

No, Danny Mayer is responsible for that. I didn't realize that was
still not done. (Which bug # is that?) I expect things will begin to
move along more smoothly after the move is complete.

By "keep up", I meant I'm trying to report promptly when the NetBSD
build breaks. I guess not many NetBSD folks are pulling from the
bitkeeper repos.

> (Now that something working is in bind-9.3/libisc the interface discovery
> code should be just sync'd.)
>
> >  ftp://ftp.netbsd.org/pub/NetBSD/misc/fredb/ntp-poll_interval.diff
>
> I've applied this to -current and compiled successfully on i386, alpha
> and amd64. I can't tell yet whether it improves anything for me.
> On i386 and alpha, it runs well, with some overshoot behaviour on startup
> which is appearently less than with 4.2.0. On the (dual-processor) amd64
> the pll frequency adjustment stays at the negative limit.
> It is not worse than before, however.

I'm convinced there's a bug in the kernel for SMP. I think
cc_microset() is responding more to the change in the amount of time
needed to take an interprocessor interrupt from tick to tick (as load
varies, say) than to any real change in the absolute length of time
of a tick. What's called for, is to average out the momentary changes.
My efforts so far just cause the system to freeze hard, though. (Ask
me off list if you want to brainstorm, or to see my patches.)


Frederick