From owner-freebsd-hackers  Mon Dec  9 17:55:20 1996
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by freefall.freebsd.org (8.8.4/8.8.4) id RAA23689
          for hackers-outgoing; Mon, 9 Dec 1996 17:55:20 -0800 (PST)
Received: from Pescadero.DSG.Stanford.EDU (Pescadero.DSG.Stanford.EDU [171.64.79.10])
          by freefall.freebsd.org (8.8.4/8.8.4) with ESMTP id RAA23684
          for <hackers@freebsd.org>; Mon, 9 Dec 1996 17:55:15 -0800 (PST)
Received: from Cup.DSG.Stanford.EDU (Cup.DSG.Stanford.EDU [171.64.79.91]) by Pescadero.DSG.Stanford.EDU (8.7.4/8.6.9) with SMTP id RAA04644; Mon, 9 Dec 1996 17:53:55 -0800
Message-Id: <199612100153.RAA04644@Pescadero.DSG.Stanford.EDU>
X-Authentication-Warning: Pescadero.DSG.Stanford.EDU: Host Cup.DSG.Stanford.EDU [171.64.79.91] didn't use HELO protocol
To: Chris G Demetriou <Chris_G_Demetriou@auchentoshan.pdl.cs.cmu.edu>
cc: Jason Thorpe <thorpej@nas.nasa.gov>, John Birrell <jb@cimlogic.com.au>,
        terry@lambert.org, hackers@freebsd.org, tech-kern@netbsd.org
Subject: Re: poll(2) 
Subject: i386 priority levels
Date: Mon, 09 Dec 1996 17:53:54 -0800
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


[alpha references snipped; the 2^10-Hz alpha clock-tick "hz" was why
 I referred to millisecond accuracy]

Quoting cgd:

>Granted, that doesn't change what you're saying re: scheduling, but
>when you add in the fact that the Alpha uses a 1024Hz real time clock
>interrupt rate, which could be easily increased, well, you're still in
>microseconds for scheduling, but are getting closer.  It's just a
>matter of time.  8-)


Uh, ``of course.''. That's why i also said:

>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).

(the "y" is a typo.)

In case it's not clear, the reason for adding nanosecond resolution is
that NetBSD has acquired POSIX .12(?)-compatible syscalls with nanosecond
resolution, and if we're going to change poll(2) to higher resolution,
I'm saying move it to nanoseconds _now_, for consistency with other
nanosecond-granularity syscalls, even if the internal implementation
doesn't offer better than millisecond (or 100s of microsecond)
resolution for some time to come.