Re: kern/47431: nanosleep is more like millisleep

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR kern/47431; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: kern/47431: nanosleep is more like millisleep
Date: Wed, 26 Mar 2014 17:48:30 +0000

 On Fri, Jan 11, 2013 at 10:05:06AM +0000, Michael van Elst wrote:
  >>>  The standard will just say that the time sleeping must be 'at least as
  >>>  long as that requested'.
  >>>  So if a program does sleeps in a loop for an interval that is a multiple
  >>>  of the timer tick they will always be one tick longer than requested.
  >> 
  >> That is very much not useful.
  >  
  >  But correct.
 
 Pedantically, yes.
 
  >>>  Don't think nanosleep can be expected to busy-wait.
  >> 
  >> Again, that's the whole point of nanosleep.
  >  
  >  The point of nanosleep is to provide a sleep function to which you
  >  can specify the sleep interval with a high resolution. But you
  >  will always get the resolution that is provided by the system
  >  modulo whatever the scheduler will allow.
  >  
  >  nanosleep may or may not use a delay loop (it shouldn't except
  >  for tiny intervals). Even then you will hardly get nanosecond
  >  resolution but whatever some hardware timer offers.
 
 Of course. I'm aware of the difference between accuracy and precision,
 thank you.
 
 That said, the whole intent of nanosleep when it was introduced
 (vs. various usleep calls or using select/poll) was to provide an
 interface where it made sense to use a timing loop to handle short
 sleeps with reasonable accuracy.
 
  >  > Nonsense. Delay loops delay exactly as long as you want. Because
  >  > NetBSD's nanosleep is defective
  >  
  >  The single problem is that the resolution of the NetBSD timer isn't
  >  fine enough for your (and many other) applications.
  >  
  >  To fix this you need to implement a high resolution timer (might be
  >  even done tickless), then nanosleep can use this instead of hardclock().
  >  The two remaining problems with this is that maybe not all platforms
  >  have a usuable high resolution timer and that even then the timer might
  >  be too coarse. But on most systems you should get a resolution of
  >  less than 100 microseconds, that's more than 100 times better than now.
 
 NetBSD already has high-resolution timecounters. I don't know what's
 entailed in making this work properly, but the point of this PR is
 that we ought to eventually get it done.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost