From owner-freebsd-hackers Sat Nov 18 22:34:09 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id WAA15901 for hackers-outgoing; Sat, 18 Nov 1995 22:34:09 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id WAA15871 for ; Sat, 18 Nov 1995 22:33:59 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id RAA22981; Sun, 19 Nov 1995 17:29:04 +1100 Date: Sun, 19 Nov 1995 17:29:04 +1100 From: Bruce Evans Message-Id: <199511190629.RAA22981@godzilla.zeta.org.au> To: cimaxp1!jb@werple.net.au, lambert.org!terry@werple.net.au Subject: Re: DELAY's in syscons Cc: hackers@FreeBSD.ORG, jb@cimlogic.com.au Sender: owner-hackers@FreeBSD.ORG Precedence: bulk >> Time to scream about high resoloution kernel timers once again? A nice >> reschedulable one-shot HRT interface would fix DELAY right up. There >> are only *minor* kernel preemption issues involved. >What are the issues about getting better time resolution in general from the >kernel? With process control software (that is threaded) running flat out in >memory (no disk or network I/O), we notice the timer resolution. >We'd also like a better nanosleep than we get using select. Is nanosleep >something you'd implement with your "reschedulable one-shot HRT interface"? Timer resolution is fine, but select() and usleep() and anything else that depends on the scheduling clock for wakeups is limited to at most the resolution of the scheduling clock (1/hz seconds). One shot timers could be used to improve the select() resolution. They would not be easy to implement without reducing the accuracy of the kernel time. They would not help fix DELAY() because DELAY() isn't allowed to sleep. They might help avoid abuses of DELAY(). They could be used to improve the resolution of timeout() and tsleep() in the same way as for select(). Note that only minimum timeouts can be guaranteed. Bruce