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_
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
> Terry Lambert