Date: Sat, 24 Jul 2004 16:36:48 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: green@freebsd.org Cc: current@freebsd.org Subject: Re: nanosleep returning early Message-ID: <20040724.163648.23387896.imp@bsdimp.com> In-Reply-To: <20040721102620.GF1009@green.homeunix.org> References: <20040721081310.GJ22160@freebsd3.cimlogic.com.au> <20040721102620.GF1009@green.homeunix.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <20040721102620.GF1009@green.homeunix.org>
Brian Fundakowski Feldman <green@freebsd.org> writes:
: On Wed, Jul 21, 2004 at 06:13:10PM +1000, John Birrell wrote:
: >
: > Today I increased HZ in a current kernel to 1000 when adding dummynet.
: > Now I find that nanosleep regularly comes back a little early.
: > Can anyone explain why?
: >
: > I would have expected that the *overrun* beyond the required time to vary,
: > but never that it would come back early.
:
: Is this a difference from clock_gettime(CLOCK_MONOTONIC)? You really
: shouldn't be using gettimeofday() foor internal timing since the
: system clock can be adjusted by NTP.
But the ntp adjustments tend to be in frequency only, and never in
phase. ntp will step the clock on startup (usually several minutes
after the system starts once it gets a good bead on the phase and
frequency of its reference system/clock). Once it has stepped,
however, it only steers the frequency of the system clock, which is
then monotonic. settimeofday does also jump system time.
Also, using CLOCK_MONOTONIC returns the uptime of the system. It can
be hard to correlate this to a wall time. CLOCK_MONOTONIC is impacted
by the frequency (but not phase) adjustements of ntp, but that's
likely what you want.
How early are things returning? If it is < 1us, then maybe you are
running into resolution issues wrt gettimeofday.
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040724.163648.23387896.imp>