Re: Fw: missed itimer signals in 2.6

From: Tom Marshall (tmarshall_at_real.com)
Date: 10/15/03

  • Next message: William Lee Irwin III: "Re: 2.6.0-test7-mm1" 
    Date:	Wed, 15 Oct 2003 09:50:16 -0700
To: George Anzinger <george@mvista.com>

    > >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).

    I expect there are at least a few applications that will misbehave because
    the developers did not expect a timer to behave this way (regardless of
    whether it's proper according to the spec).

    Is it possible to choose a timer resolution that errs on the high side of
    1ms instead of the low side? [*] It seems to me that would result in the
    application getting very close to the expected number of alarm signals. I
    am not at all familiar with the kernel design so I don't know if this would
    be feasible or not.

    [*] If this is the 8254 timer, using 1192 as a divisor should result in a
    resolution of ~1,000,686 nanoseconds. 

    -- 
I mean, if 10 years from now, when you are doing something quick and dirty,
you suddenly visualize that I am looking over your shoulders and say to
yourself, "Dijkstra would not have liked this", well that would be enough
immortality for me.

    -
    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: William Lee Irwin III: "Re: 2.6.0-test7-mm1"

    Relevant Pages

    • Re: Fw: missed itimer signals in 2.6
      ... So the kernel figures out what the true PIC rate is and sets up ... This results in a resolution of ~999,849 ... > Is it possible to choose a timer resolution that errs on the high side of ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5
      ... low resolution, low overhead timer optimized for kernel needs and process ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [RFC][PATCH] new timeofday core subsystem (v.A0)
      ... On Wednesday, September 8, 2004 9:31 pm, George Anzinger wrote: ... resolution. ... If you don't put a limit on this you will invite timer ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: High res timer?
      ... > We're currently using pth_usleepas a timer for a userspace audio ... > there a better timer that we can call form a userspace ... If you need better resolution, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • 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)
    Loading