From owner-freebsd-current  Mon Apr  7 15:16:52 1997
Return-Path: <owner-current>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.5/8.8.5) id PAA17611
          for current-outgoing; Mon, 7 Apr 1997 15:16:52 -0700 (PDT)
Received: from spinner.DIALix.COM (root@spinner.dialix.com [192.203.228.67])
          by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id PAA17605
          for <freebsd-current@freebsd.org>; Mon, 7 Apr 1997 15:16:46 -0700 (PDT)
Received: from spinner.DIALix.COM (peter@localhost.DIALix.oz.au [127.0.0.1])
          by spinner.DIALix.COM (8.8.5/8.8.5) with ESMTP id GAA03730;
          Tue, 8 Apr 1997 06:15:09 +0800 (WST)
Message-Id: <199704072215.GAA03730@spinner.DIALix.COM>
X-Mailer: exmh version 2.0gamma 1/27/96
To: Terry Lambert <terry@lambert.org>
cc: freebsd-current@freebsd.org
Subject: Re: POLL & the Single FreeBSD'r 
In-reply-to: Your message of "Mon, 07 Apr 1997 14:41:58 MST."
             <199704072141.OAA02263@phaeton.artisoft.com> 
Date: Tue, 08 Apr 1997 06:15:09 +0800
From: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Terry Lambert wrote:
> > What you want is a high-resolution timer/sleep/schedule system, which we
> > don't have, and nobody has offered to implement yet, so it's pretty 
> > unlikely that we'll see it in the near future.  (This doesn't mean that it 
> > cannot be done, just that nobody has wanted it badly enough to do it.  
> > Messing with timers and a more precise sleep queue that can deal with the 
> > next event in microseconds for the timer programming might be enough, 
> > especially when combined with the RT schedule options)
> 
> Yes; kernel preemtion on timer events before process quantum expiration
> is probably 90% of the way to real RT support...
> 
> I don't necessarily want something with high-resoloution timing right
> now, but the select() code *will* operate sub-quantum if there's nothing
> else in the run queue without "real" high resoloution support.  SunOS 4.x
> has historically worked that way (down to 4uS on a select/timeout buzz
> loop on a SPARCStation 1+, actually... better on faster hardware).

Hmm.. this is an interesting suggestion..  I think we can do the same with 
some careful use of microtime() and mi_switch()..

> scheduler can't keep up, then it can't keep up (the part of the man
> page I was referrung to was the tv_usec reference). 

peter@spinner[6:07am]~src/sys/kern-132> man select | col -b | grep tv_
peter@spinner[6:11am]~src/sys/kern-133>
What tv_usec reference?  Are you on the wrong system? :-)

Our 4.4BSD derived man page only says the word "timeout" and mentions nothing 
about tv_* at all

> 					Regards,
> 					Terry Lambert
> 					terry@lambert.org

Cheers,
-Peter