From owner-freebsd-hackers Thu Jul 2 07:32:05 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01858 for freebsd-hackers-outgoing; Thu, 2 Jul 1998 07:32:05 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: (from sos@localhost) by hub.freebsd.org (8.8.8/8.8.8) id HAA01792; Thu, 2 Jul 1998 07:31:33 -0700 (PDT) (envelope-from sos) Message-Id: <199807021431.HAA01792@hub.freebsd.org> Subject: Re: timeout granularity (was: Re: Console driver...) In-Reply-To: from =?ISO-8859-1?Q?Dag=2DErling_Coidan_Sm=F8rgrav?= at "Jul 2, 98 03:34:07 pm" To: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan Smørgrav) Date: Thu, 2 Jul 1998 07:31:33 -0700 (PDT) Cc: luigi@labinfo.iet.unipi.it, sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG From: sos@FreeBSD.ORG Reply-to: sos@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In reply to Dag-Erling Coidan Smørgrav who wrote: > Luigi Rizzo writes: > > > It's not that simple. You have to know how long to wait, which is > > > practically impossible to do without hooking the timer interrupt and > > > reprogramming it to keep pace with the retrace, and even that is > > > difficult to achieve without a little busy-waiting here and there. > > a little busy waiting is not a lot. What is bad is 10ms waiting > > With a 70 Hz refresh rate, we're talking more like 14 ms in the worst > case, which is pretty darn bad. Yup, but... > > If one can, say, assume that the vertical retrace is never less than > > 1ms, then HZ=2000 should do the job (wakeup at every tick...). > > Ah, I didn't think of it quite like that. Yes, it would work, and you > wouldn't have to busy-wait at all; just wake up at every tick, check > if you're in a retrace, and if you are, do your job. You will have to be more accurate than that... Its right that you have to wait ~14ms, but the window of opportunity (ie in the blanking period) is only about 330 usecs long, and you have to hit it pretty accurately (ie within a few 10 usec) to be able to do the transfer without shooting over the edge. So there goes that idea, belive me I've thought of this before :) Besides rasing the clock that drastically will impact on our slower customers, I'd say generally its a bad idea... (And I did the code that allows it for the pca device, hi hi hi) -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Soren Schmidt (sos@FreeBSD.org) FreeBSD Core Team So much code to hack -- so little time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message