lkml.org 
[lkml]   [2002]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: HZ, preferably as small as possible
    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
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:27    [W:4.609 / U:0.012 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site