Re: nanosleep returning early

On Wed, Jul 21, 2004 at 11:01:20PM +1000, Bruce Evans wrote:
> On Wed, 21 Jul 2004, Brian Fundakowski Feldman wrote:
> > 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?
> 
> The most obvious bug is that nanosleep() uses the low-accuracy interface
> getnanouptime().  I can't see why the the problem is more obvious with
> large HZ or why it affects short sleeps.  From kern_time.c 1.170:
> 
> % static int
> % nanosleep1(struct thread *td, struct timespec *rqt, struct timespec *rmt)
> % {
> % 	struct timespec ts, ts2, ts3;
> % 	struct timeval tv;
> % 	int error;
> %
> % 	if (rqt->tv_nsec < 0 || rqt->tv_nsec >= 1000000000)
> % 		return (EINVAL);
> % 	if (rqt->tv_sec < 0 || (rqt->tv_sec == 0 && rqt->tv_nsec == 0))
> % 		return (0);
> % 	getnanouptime(&ts);
> 
> This may lag the actual (up)time by 1/HZ seconds.

For any NTP clock adjustment to have an effect, it must happen between
the time when my (crude) test gets the time and when the kernel calls
getnanouptime to fill ts. All the rest of the code in nanosleep1()
refers back to the value of ts. Any errors involved in the tv and hz
conversions would just cause the code to go around the loop and tsleep
more than once.

So, does increasing HZ expose the lower accuracy of getnanouptime() and is
that what I'm seeing?

If so, shouldn't the time interface provided by the kernel to userland
at least be consistently inaccurate? Or put another way, why should
nanosleep be any less accurate than gettimeofday? 


Bruce, have you seen this document: <http://www.dragonflybsd.org/docs/nanosleep/>?
I'm not looking for a critique here. The document talks about the sleep
overruns in various operatingg systems. There is a patch that was applied
to DragonFly which aplies to the FreeBSD code base too.

-- 
John Birrell