Date: Mon, 24 Jan 2000 11:59:38 -0500 (EST) From: Mikhail Teterin <mi@aldan.algebra.com> To: Vivek Khera <khera@kciLink.com> Cc: stable@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <200001241659.LAA34219@misha.cisco.com> In-Reply-To: <14476.31150.689748.108097@onceler.kcilink.com> from Vivek Khera at "Jan 24, 2000 11:11:26 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Vivek Khera once wrote: > >>>>> "MP" == Mattias Pantzare <pantzer@ludd.luth.se> writes: > > MP> The problem is simply that the kernel that has a lower resolution > MP> on it's scheduling than the clock that you are using, and that it > MP> takes time to do things on a noral CPU. > > Plus the fact that FreeBSD is *not* a real-time OS, so any time > guarantees are not really guarantees, just suggestions. If you want > hard real-time constraints, you'll need to use a real-time OS. This alone would explain why it would occasionaly exceed the specified timeout. It does not explain the consistent 9-10 msecs excess. Especially on an idle machine. As was pointed out, (all/most of) the Unix man pages are contradicting the POSIX spec, which says, the specified value is the _minimum_, rather then maximum time to wait as the man-pages say. When I find a URL to the spec myself, I'll take it to the TCL's forum to push for changes in the TCL's after(n) implementation. -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001241659.LAA34219>