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: Fri, 11 Jan 2013 08:55:18 +0000

 On Fri, Jan 11, 2013 at 08:25:05AM +0000, David Laight wrote:
  >  >    - For all time values >= 20 ms, the resulting delay is nearly
  >  >      always the requested time plus 9.99 ms, or sometimes a bit more
  >  >      than that. That is, even if the requested delay is an integer
  >  >      number of scheduler quanta, we always sleep for one more.
  >  
  >  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.
 
  >  > Ostensibly if one wants to sleep for small amounts of time, one is
  >  > supposed to busy-loop; this is fine. However, nanosleep is supposed to
  >  > do this for me, and do it in the kernel where ready access to
  >  > fine-grained timing is available. This is arguably the whole point of
  >  > nanosleep(*).
  >  
  >  Don't think nanosleep can be expected to busy-wait.
 
 Again, that's the whole point of nanosleep.
 
  >  In any case, very short busy-waits don't have the desired effect
  >  (they are either much longer than wanted,
 
 Nonsense. Delay loops delay exactly as long as you want. Because
 NetBSD's nanosleep is defective I had to roll my own today, and
 without trying very hard or really bothering to calibrate anything in
 much detail, got myself something good to a few microseconds on
 average. This was not very difficult, and it's much easier if you can
 get at a useful time reference without paying the overhead of a system
 call.
 
 Fixing the system so it can do timing at higher resolution will
 actually take work, but adding some timing loop logic should not be
 very involved.
 
  >  or you are trying to separate
  >  bus cycles and delays in bridges (etc) mean the cycles can get moved
  >  together).
 
 ENOPARSE?
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost