Skip site navigation (1)Skip section navigation (2)
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>