From owner-freebsd-hackers Fri May 3 10:43:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by hub.freebsd.org (Postfix) with ESMTP id 4F61A37B404 for ; Fri, 3 May 2002 10:43:30 -0700 (PDT) Received: from pool0248.cvx40-bradley.dialup.earthlink.net ([216.244.42.248] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 173h5a-0000v4-00; Fri, 03 May 2002 10:43:27 -0700 Message-ID: <3CD2CC22.C7B6918F@mindspring.com> Date: Fri, 03 May 2002 10:42:58 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dominic Marks Cc: Paolo Di Francesco , freebsd-hackers@FreeBSD.ORG Subject: Re: A time resolution problem References: <3CD29602.24230.34C2C21@localhost> <20020503130031.A790@host217-39-140-82.in-addr.btope> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Dominic Marks wrote: > On Fri, May 03, 2002 at 01:52:02PM +0200, Paolo Di Francesco wrote: > > Now the problem is that I want to know if it is possible, and > > how, to schedule events with a precision greater (or equal to)) > > than 1ms. Maybe an approach with posix timers? Maybe move the app > > into the kernel space? Maybe change the scheduler? > > KEvent has EVFILT_TIMER to allow you to return after a period. It > takes a struct timespec as its argument, which goes down to nanosecond > resolution. If it is practically useful at such small intervals I do > not know, but its possibly in theory. The practical limit on the bottom end is one quantum plus context switch overhead. This assumes that your process is running at rtprio, and no other process is, so that given a choice, each context switch, your process has the opportunity to run if it needs to. The maximum length of a quantum is controllable via sysctl; the default is 100000 (or 100ms). So you should not expect that your maximum timer resolution will be better than 100ms, even if you use rtprio, unless you change this away from the default to something smaller. And the smaller you go, the more context switch overhead you will have relative to the amount of time you spend doing real work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message