From owner-freebsd-stable Mon Jan 24 9: 0: 4 2000 Delivered-To: freebsd-stable@freebsd.org Received: from misha.cisco.com (misha.cisco.com [171.69.206.50]) by hub.freebsd.org (Postfix) with ESMTP id 4CBF214CD4 for ; Mon, 24 Jan 2000 08:59:51 -0800 (PST) (envelope-from mi@misha.cisco.com) Received: (from mi@localhost) by misha.cisco.com (8.9.3/8.9.1) id LAA34219; Mon, 24 Jan 2000 11:59:38 -0500 (EST) (envelope-from mi) Message-Id: <200001241659.LAA34219@misha.cisco.com> Subject: Re: kern/13644 In-Reply-To: <14476.31150.689748.108097@onceler.kcilink.com> from Vivek Khera at "Jan 24, 2000 11:11:26 am" To: Vivek Khera Date: Mon, 24 Jan 2000 11:59:38 -0500 (EST) Cc: stable@FreeBSD.ORG Reply-To: mi@aldan.algebra.com From: Mikhail Teterin X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Vivek Khera once wrote: > >>>>> "MP" == Mattias Pantzare 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