Re: Fw: missed itimer signals in 2.6

From: George Anzinger (george_at_mvista.com)
Date: 10/15/03

  • Next message: Robert L. Harris: "Bad clock? battery?" 
    Date:	Wed, 15 Oct 2003 08:11:38 -0700
To: Tom Marshall <tmarshall@real.com>

    Tom Marshall wrote:
    >>Since the actual interval used by the system is a bit larger than what
    >>was asked for, there will be fewer ticks.
    >
    >
    > I understand what happens and why. I admit that I'm not familiar with the
    > POSIX standard on this issue. Questions:
    >
    > * I've heard that the kernel's timer resolution has increased from 10ms to
    > 1ms in 2.6. Why does the itimer have such a large granularity? I
    > expected it to be highly accurate in this range.

    I think it is. The missing understanding is, I think, that you expect the
    resolution to be exactly 1/HZ or 1ms. It is actually not exactly that because
    the PIC can not generate 1ms interrupts (close but not close enough for NTP).
    So the kernel figures out what the true PIC rate is and sets up the resolution
    for that. This results in a resolution of ~999,849 nanoseconds (i.e. instead of
    1,000,000 nano seconds per tick). Now there is some errors in converting this
    to micro seconds..., but the actual math is done with more precision with the
    conversion after (which is why the various times the program tries don't come
    out being exact multiples of each other, or of anything expressed as only
    microseconds).
    >
    > * Is this how the timer is supposed to work? It seems to me that an
    > algorithm which kept running track of the difference in requested and
    > actual times (a la Bresenham) could make the itimer behave closer to what
    > the user requested.

    I THINK you are suggesting that a different increment be used each timer expiry
    to get closer to the desired rate. Sorry, not only is this a LOT more overhead,
    it is not the way the standard is written. The standard says all these times
    are to be rounded up to the resolution, which is what the system does. It is
    just that the resolution is not what you expect.

    For what its worth, the POSIX clocks and timers (accessed through timer_settime,
    etc.) compute time to the nanosecond, so they will have less rounding error and
    will be a tad closer to the requested. Still, we are dealing with an underlying
    ticker that only has 999,849 nanosecond resolution.

    Hope this helps

    George
    >
    >
    >>Maybe you could save this code if it is part of a test suite....
    >
    >
    > This code is part of a "timer calibration" routine used by the RealNetworks
    > Helix Server. I just noticed that the timer calibration failed on a machine
    > that had 2.6.0-test7 installed (we have not officially looked at supporting
    > 2.6 yet). The test runs on many different flavors of *nix (probably a dozen
    > or so). I can check to see what the behavior is on the other platforms if
    > that would be useful. If this is the Right Way to do timers, we'll probably
    > end up changing our "calibration" routine to read back the actual timer
    > interval as you suggest.
    > 

    -- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml
-
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/
  • Next message: Robert L. Harris: "Bad clock? battery?"

    Relevant Pages

    • Re: [patch 00/21] hrtimer - High-resolution timer subsystem
      ... Right now the primary function of the state is to tell whether the timer ... > Of course if you consider the possibility of including high resolution ... problem requires solving problems in the clock abstraction first, ...
      (Linux-Kernel)
    • Re: [patch 00/21] hrtimer - High-resolution timer subsystem
      ... >> This way the list head is only necessary for the high resolution case. ... > (e.g. wakeup + timer restart). ... Even if the clock ...
      (Linux-Kernel)
    • Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
      ... >>The cleanup I pointed out for the posix timer interval timers is pretty ... >>the posix timer structure. ... The rounding to the resolution value is explicitly required by the ... This says a) round to the next resolution, and b) don't allow the resulting timer to expire early. ...
      (Linux-Kernel)
    • Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
      ... > a clock with a better resolution. ... > resolution than the physical clock has. ... reaches this count the timer is expired. ... OTOH We could also do this at the timer interrupt: ...
      (Linux-Kernel)
    • Re: VB6 code runs different speeds on different PCs
      ... As you've discovered, the minimum Sleep period can be different on different machines (5 milliseconds on my own WinXP system, but longer than that on others I think). ... You can get whatever "game rate" you want in a closed loop of course, by checking a high resolution timing source. ... If I were you I would use a proper Timer with a higher resolution that the standard VB Timer and run your entire game in the Timer event. ... Admittedly, updating their positions more than once every ten milliseconds does appear to give smoother animation (even though the video frame rate simply cannot draw a new frame at a rate greater than every 10 milliseconds,or so, depending on your display settings) because it tends iron out the differences more. ...
      (microsoft.public.vb.general.discussion)