> >Just wanted to get tech-kern@netbsd.org on this thread, too :-)
> >
> >"Discuss." :-)
> 
> Uh, well, then....
> 
> AFAIK, there aren't yet any NetBSD ports with significantly
> better than millisecond time-of-day-clock (and thus forced process-
> scheduling) resolution.  So milliseconds are currently as good as
> you'll get.
> 
> You can add a syscall specifying a nanosecond interval, but anyone
> thinking they're going to get _nano_second-level wakeups is,
> currently, deluding themselves.  (I still get ~4usec syscall times on
> a 200MHz P6.)

The Sun SPARCServer 2 also has a timer resoloution of ~4uS; this was
tested with itimers + gettimeofday() after timer firing, so it does
include significant system call overhead.

I think the scheduling limitation of 100Hz limits the guaranteee
resoloution to 10ms, at best (gettimeofday() value update frequency
for the SVR4 scheduler module... SVID specifies system clock update
frequency... SVR4 is not SVID compliant).  If a process consumes it's
entire quantum, it will not switch for 10ms without kernel preemption
based on a timer event being capable of forcing a kernel-level context
switch.  Practically, this becomes a maximum of:

	10ms + min( 10ms, timer_duration) - 1

If the process in line before the timer expiry process consumes its
full quantum.  This assumes that timer expiry events result in the
process moving to the head of the scheduler queue.

Really, good timers is the province of kernel preemption -- and extension
for RT scheduling support.  When I make an setitimer/getitimer call, I
am *truly* interfacing into the RT services (which is why they are
listed in section "(RT)" in SVID III).


> Clearly we should add a nano-second resolution poll interface.
> Once we do so, regardless of the actualy in-kernel resolution,
> poll(2) and upoll(3) become poll(3) and upoll(3).

Yes.  This is a good idea in general; it shows good future planning.
A 550MHz PPC processor is said to be shipping next year... as we
approach GHz speds, nS resoloution becomes likely.  At the very least,
we are talking sub-uS resoloution, which requires those units be used
in any case.


> Re naming, npoll() is more consistent with the sleep()/usleep() usage.
> Does POSIX have anything to say here?

No.  All of POSIX is permitted to be implemented in libc as nothing
more than wrappers.  VMS is POSIX compliant, for instance, if you have
the VAX C Runtime Environment (well, except the record seek pointer
is not advanced after the implied carriage control from a record has
been implied into the input stream -- but that's another story).


> If we did this _now_ we could, perhaps, reuse the existing syscall
> number,  since AFAIK poll(2) has never been in an official NetBSD release.

Yes.  The only conflict is call gate for ABI with some other OS that
does poll with which you want binary compatability.  Solaris might
be one example.  It really depends on whether execution classes imply
system call interfaces, or not (they should, meaning no conflict).


					Regards,
					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.