Date: Sun, 23 Jan 2000 18:14:23 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Mikhail Teterin <mi@kot.ne.mediaone.net> Cc: Jason Evans <jasone@canonware.com>, David Schwartz <davids@webmaster.com>, bde@FreeBSD.ORG, hackers@FreeBSD.ORG Subject: Re: kern/13644 Message-ID: <20000123181423.W26520@fw.wintelcom.net> In-Reply-To: <200001240126.UAA44772@rtfm.newton>; from mi@kot.ne.mediaone.net on Sun, Jan 23, 2000 at 08:26:15PM -0500 References: <20000123121055.F27689@sturm.canonware.com> <200001240126.UAA44772@rtfm.newton>
next in thread | previous in thread | raw e-mail | index | archive | help
* Mikhail Teterin <mi@kot.ne.mediaone.net> [000123 17:51] wrote:
> Jason Evans once stated:
>
> =I thought Bruce was pretty clear when he explained that such upper
> =bounds are not possible unless the operating system can make hard
> =real-time guarantees.
>
> His explanation contradicted ALL of the documentation I was able to
> find, and he chose not to comment on the contradiction.
>
> =FreeBSD is clearly not capable of hard real-time. If I remember
> =correctly, neither are any of the operating systems from which you
> =quoted man pages. That makes *all* of those man pages inaccurate.
>
> In other words, we found a flow in the most (all?) Unix implementations?
> Including FreeBSD. Alright.
>
> =In fact, as explained in earlier email, the timeout is rounded up in
> =order to be certain that the process isn't woken up too early.
>
> I did not want to be dragged into discussing the implementation, which
> is something I'm only beginning to learn. But, perhaps, it can be
> rounded DOWN instead? An application written by the man-page will expect
> to be waken up EARLY (like TCL's implementation of after(n)), but no
> man-page hints at the possibility to be waken up LATE. And yes, it
> should, of course, understand that it may not actually get to run
> because of the scheduling issues.
>
> =Our man page is wrong:
> =
> = If timeout is a non-nil pointer, it specifies a
> = maximum interval to wait for the selection to complete.
>
> =If you can come up with some better wording that you can convince a
> =committer is accurate and comprehensible, you might consider pursuing
> =this issue. That's the only direction I have any interest in following
> =this discussion in, however.
>
> That's very nice, thank you. How about re-opening the PR?
>
> Peter Jeremy wrote:
>
> =Please provide a test program and results from these other vendors
> =demonstrating that their select() will return before the specified time
> =limit in the absence of any other event.
>
> Never claimed it will... All of the man pages say, it is possible,
> though. They do NOT say it is possible to return AFTER. Of course, the
> program may not get to actually run right then. Just like it may be
> delayed returning from a printf()...
>
> The test program is very simple -- one line of TCL:
>
> time {after 20} 100
>
> This will report how many microseconds did a select for 20 milliseconds
> _really_ take -- an average over 100 attempts. On an idle DUAL processor
> PentiumII-300, with 3.4-STABLE, the typical result is 29937 microseconds
> per iteration. On SunOS tornado 5.5.1 Generic_103640-24 sun4m sparc
> SUNW,SPARCstation-20 it is a little better: 28167 microseconds per
> iteration. Similarly for Irix. The TCL's over-head can be measured by
> something simple, like:
>
> time {set a 5} 100
> 3 microseconds per iteration # On FreeBSD
> 16 microseconds per iteration # On SunOS
> 28 microseconds per iteration # On Irix 6.5
>
> HOWEVER! The reason I brought up the other vendors, was not to
> claim, their IMPLEMENTATION was better then FreeBSD's, but that their
> DOCUMENTATION was the same as ours. Bruce was saying our man page is
> broken. I wanted him, or someone else, to confirm that all those other
> vendors are incorrect in their man pages too.
>
> You are saying, the man-pages are correct (contradicting Bruce)...
No the manpages are wrong on every single system you've mentioned as
it's nearly impossible to return to the user in the exact amount of
time specified.
I'll be fixing the manpage shortly, you should contact other vendors.
--
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000123181423.W26520>