Subject: Re: lazy mlock?
To: Bill Studenmund <wrstuden@netbsd.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 04/18/2002 13:37:18
In message <Pine.NEB.4.33.0204181318560.5446-100000@vespasia.home-net.internetconnect.net>, Bill Studenmund writes

>Would it be reasonable for ntp to make a few trials, to get the parts of
>it that it needs paged in, and then do "real" timings? That way the parts
>that are actually used are locked down but not everything else.

NTP tries to ramp up its polling intervals: after it becomes happy at
a given interval, it tries doubling the interval (up to 1024 secs,
by default).

One can configure newer v4 ntpd to exchange several "chimes" on each
poll. IIRC, the intersection algorithm discards samples from clock
sources, rather than discarding the first packet of each poll as a
`trial'.  If a machine has really heavy paging load, it might well
page out part of ntpd's critical code path between the `trial' and
`real' packets.

(This becomes a much sorer point for nanosecond-resolution
 timekeeping, but that's a different issue.)