From owner-freebsd-hackers Mon Dec 9 17:37:42 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA22790 for hackers-outgoing; Mon, 9 Dec 1996 17:37:42 -0800 (PST) Received: from auchentoshan.pdl.cs.cmu.edu (AUCHENTOSHAN.PDL.CS.CMU.EDU [128.2.189.1]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA22785 for ; Mon, 9 Dec 1996 17:37:39 -0800 (PST) Received: from localhost by auchentoshan.pdl.cs.cmu.edu id aa03127; 9 Dec 96 20:36 EST To: Jonathan Stone cc: Jason Thorpe , John Birrell , terry@lambert.org, hackers@freebsd.org, tech-kern@netbsd.org Subject: Re: poll(2) In-reply-to: Your message of "Mon, 09 Dec 1996 17:09:57 PST." <199612100109.RAA04353@Pescadero.DSG.Stanford.EDU> Date: Mon, 09 Dec 1996 20:35:44 -0500 Message-ID: <18951.850181744@auchentoshan.pdl.cs.cmu.edu> From: Chris G Demetriou Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > 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. On a single-processor alpha, you can sanely get down-to-the-cycle time of day clock resolution. You can't schedule on it, but you can get it e.g. for microtime(), etc. I implemented that in NetBSD/alpha (along with a memory mapped clock that provided the same resolution), then yanked it because i didn't want to create an interface which would be more or less impossible to provide on MP systems. 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-) chris