Date: Mon, 09 Dec 1996 20:35:44 -0500 From: Chris G Demetriou <Chris_G_Demetriou@auchentoshan.pdl.cs.cmu.edu> To: Jonathan Stone <jonathan@dsg.stanford.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) Message-ID: <18951.850181744@auchentoshan.pdl.cs.cmu.edu> In-Reply-To: Your message of "Mon, 09 Dec 1996 17:09:57 PST." <199612100109.RAA04353@Pescadero.DSG.Stanford.EDU>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?18951.850181744>