Re: HZ, preferably as small as possible

[Vojtech Pavlik <vojtech@suse.cz>]

On Mon, Jul 15, 2002 at 05:06:45AM +0000, Linus Torvalds wrote:
> In article <59885C5E3098D511AD690002A5072D3C02AB7F88@orsmsx111.jf.intel.com>,
> Grover, Andrew <andrew.grover@intel.com> wrote:
> >
> >But on the other hand, increasing HZ has perf/latency benefits, yes? Have
> >these been quantified?
> 
> I've never had good reason to believe the latency/perf benefits myself,
> but I was approached at OLS about problems with something as simple as
> DVD playing, where a 100Hz timer means that the DVD player ends up
> having to busy-loop on gettimeofday() because it cannot sanely sleep due
> to the lack in sufficient sleeping granularity.
> 
> You apparently end up visibly missing frames - a frame is just 3 timer
> ticks at 100 Hz, and considering that the kernel has to round up by one
> due to POSIX requirements _and_ considering that you lose roughly one
> for actually processing the frame itself, that doesn't sound _that_
> outlandish. 

Actually, this example is pretty much false I believe.

Since there is always the screen refresh rate going at say 85 Hz, you'll
be missing frames anyway.

The really correct solution would be to use the vertical blank
interrupt, which all recent cards provide, to wake the X process to tell
it that it should flip it's xvideo double-buffer (*), and to tell the
DVD player to supply another frame to it, which it would then preferably
DMA over AGP straight into the video card memory.

Now, if you wanted a real smooth video, you'd set your screen refresh
rate to 100 Hz in Europe and 120 Hz in US. (Without that it never can be
100% smooth anyway). And it also has the nice side effect of eliminating
the screen flicker caused by fluorescent lamp interference.

(*) If our interrupt-to-wake latency is too large for X to do the buffer
flip in the vblank, then we'll probably need some more kernel support
for that.

-- 
Vojtech Pavlik
SuSE Labs