Date: Thu, 02 Jul 1998 10:40:17 -0700 From: Mike Smith <mike@smith.net.au> To: Luigi Rizzo <luigi@labinfo.iet.unipi.it> Cc: smoergrd@oslo.geco-prakla.slb.com (Dag-Erling Coidan =?iso-8859-1?Q?Sm=F8rgrav?=), sos@FreeBSD.ORG, nick.hibma@jrc.it, hackers@FreeBSD.ORG Subject: Re: timeout granularity (was: Re: Console driver...) Message-ID: <199807021740.KAA00803@antipodes.cdrom.com> In-Reply-To: Your message of "Thu, 02 Jul 1998 15:26:10 %2B0200." <199807021326.PAA12564@labinfo.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
> > With a 70 Hz refresh rate, we're talking more like 14 ms in the worst > > case, which is pretty darn bad. > > > > > 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. > > actually, if you could only know how far away you are from the retrace > (perhaps by reading some status register ?) you could even tolerate a > coarser timer. Timer delivery for a value X is always > now + X, courtesy of splclock(). Please believe Soren when he says that this is simply not workable. If you *really* want to improve this, you should be thinking about how to enable the hardware cursor on your favorite video adapters. 8) -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807021740.KAA00803>