David Laight <david@l8s.co.uk> writes:
> On Tue, Apr 16, 2002 at 04:13:27PM -0700, Jason R Thorpe wrote:
> > On Tue, Apr 16, 2002 at 11:48:32PM +0100, David Laight wrote:
> > 
> >  > If it isn't a silly question, why should ntpd 'lock down' any code at all?
> > 
> > Because it is very sensitve to being able to react to a message.  Making
> > it wait to page in something will skew its results.
> 
> So will network delays, paging in U and/or P areas etc....

NTP computes network delays just fine. It has algorithms for doing
that. Dealing with code not being executed while it is being paged is
a serious problem.

> If latency is that important (and it were solaris or SVR4), I would
> push a streams module onto the UDP? stream and respond from within
> the kernel.

So, if you've pushed something into the kernel, what you're doing is
changing (effectively) how you've locked down the pages, not that
you've locked them down. It is nicer and cleaner from a debugging
perspective to leave the thing in userland, and works quite well. I
would agree that if we could get substantially better timings, moving
the code to the kernel might be good for that reason, but then we'd
also have to deal with maintaining the code ourselves instead of
letting the timelords do it.

-- 
Perry E. Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you..."