Date: Sun, 8 Dec 2002 00:10:03 -0800 (PST) From: Bruce Evans <bde@zeta.org.au> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/46036: inaccurate timeouts in select(),nanosleep() + fix Message-ID: <200212080810.gB88A3vF098758@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/46036; it has been noted by GNATS.
From: Bruce Evans <bde@zeta.org.au>
To: Enache Adrian <enache@rdslink.ro>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/46036: inaccurate timeouts in select(),nanosleep() + fix
Date: Sun, 8 Dec 2002 19:06:45 +1100 (EST)
On Sun, 8 Dec 2002, Enache Adrian wrote:
> On Sat, Dec 07, 2002 at 11:57:40PM +1100, Bruce Evans wrote:
> > tvtohz() actually adds 1 to ensure that the sleep time is at least the
> > specified time. This gives a minimum sleep time of 0.0 ticks longer
> > than the specified sleep time (as required by standards) and a maximum
> > sleep time of about 1.0 tick longer than the specified sleep time,
> > with an average sleep time of about 0.5 ticks longer. Not adding 1
> > would give a {min,max,avg} sleep time of about {-1.0,0.0,-0.5} ticks
> > longer than specified; i.e., it would be shorter than specified (broken)
> > in most cases.
> ...
> > and we are mostly in sync with clock interrupts. In general the error
> > from not adding 1 is up to 1 tick (see above).
> The average sleep time seems to be with ~ 0.995 longer on an idle
I think you mean 0.009950.
> machine - much longer on a loaded one where ticks are lost.
Hopefully ticks won't be really lost (in the kernel), although they can
be and are lost due to bugs. Ticks man be lost as far as applications
can see of course.
> For the error to be down to -1 tick with an average of -0.5 ticks
> (when not adding 1) the tick value must be very small - this doesn't
> seem to happen with the standard 100hz. Under high load the error
> tends to be positive.
It does (would) happen for random timeouts. If you look at the clock
in a loop then you normally see timeouts of ((1 tick) - epsilon)
(when not adding 1) or ((2 ticks) - epsilon) (when adding 1) because
the first one syncs with the clock. E.g., nanotime({1 nsec}) normally
returns at a time epsilon after a clock tick occurs, so a subsequent
nanotime({1 nsec}) will wait a full clock tick or two (less epsilon)
(if nanotome() is implemented using clock ticks even for short intervals).
> When the user has asked for something not multiple of tick the
> value will be correctly rounded up by tvtohz() and the error will
> be positive too.
No. E.g., if the interval is 9999 usec then it will be rounded up
to 1 tick (10000 usec). The next clock tick may occur after 1 usec,
so if 1 tick is not added then the timeout will return after 1 usec
(plus epsilon) instead of after the requested 9999 usec.
> > I thought that Linux gets timeouts right -- at least sleep() used to
> > work except in very early versions of Linux-0.x. Perhaps it uses
> ...
> Only nanosleep() works like in FreeBSD ( one tick longer by just
> adding one - this is why many recommend to use select() instead
> of usleep() ...)
This is a bug in Linux :-).
> Does it exist a standard specification for this case ?
> A quick browsing through susv3 shows that only nanosleep()
> is required to do so:
> functions/select.html:
> "If the timeout parameter is not a null pointer,
> it specifies a maximum interval to wait for the
> selection to complete."
> functions/nanosleep.html
> "But, except for the case of being interrupted by
> a signal, the suspension time shall not be less than
> the time specified by rqtp, as measured by the
> system clock CLOCK_REALTIME"
select() and its timeouts are now specified in POSIX, not quite
as clearly as this. From draft7 of POSIX.1-200x:
%%%
31187 limitations on the granularity of timeout intervals. If the requested timeout interval requires a
31188 finer granularity than the implementation supports, the actual timeout interval shall be rounded
31189 up to the next supported value.
%%%
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212080810.gB88A3vF098758>