[lkml]   [2005]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

    On Wed, 12 Oct 2005, George Anzinger wrote:

    > > > > > As far as I understand SUS timer resolution is equal to clock
    > > > > > resolution
    > > > > > and the timer value/interval is rounded up to the resolution.
    > > > >
    > > > > Please check the rationale about clocks and timers. It talks about
    > > > > clocks and timer services based on them and their resolutions can be
    > > > > different.
    > Well, yes and no. Under timer_settime() it talks about ticks and resolution
    > being the inverse of the tick rate. AND it does imply that timers on a given
    > CLOCK will have that clocks resolution as returned by clock_res(). This is
    > fine as far as it goes. In practical systems we almost always have a much
    > higher resolution for the clock_gettime() and gettimeofday() than the tick
    > rate. What the standard does not seem to want to do is to admit that a clock
    > may have the ability to be read at a better resolution than its tick rate.

    The interesting question is what resolution has CLOCK_REALTIME really?
    This paragraph in timer_settime() doesn't mention CLOCK_REALTIME and
    AFAICT historically the resolution of e.g. gettimeofday() was really in
    the msec range.

    IMO there is a far more interesting in sentence under clock_getres(): "If
    the time argument of clock_settime() is not a multiple of res, then the
    value is truncated to a multiple of res."
    This is relatively obvious for hardware clocks, e.g. we could define a
    CLOCK_JIFFIES with a resolution of TICK_NSEC or CLOCK_PIT with a
    resolution of 838 nsec. The conversion from the actual clock value to/from
    timespec automatically takes care of any truncation/rounding.

    CLOCK_REALTIME is now a bit special as it doesn't map directly to a
    hardware clock, it also includes adjustments and these are done in nsec
    resolution (actually even fractions of that in the NTP code). In 2.6 we
    don't truncate the value anywhere and maintain it as a nsec value,
    therefore the resolution of CLOCK_REALTIME should really really 1 nsec
    (and 1 usec under 2.4).

    OTOH the precision with which the clock can be read is a different matter
    and depends on the hardware clock CLOCK_REALTIME is derived of. It would
    really help if we could agree on something what clock resolution really
    means (especially for CLOCK_REALTIME). For hardware clocks the resolution
    is defined by the conversion factor from clock cycles to timespec, but
    CLOCK_REALTIME is a virtual clock, so is its resolution the precision with
    which the clock can be read or written? clock_getres() specifically
    mentions clock_settime()...

    Depending on this is how we define what timer resolution means. Currently
    we convert the timespec value from/into a jiffies value, so I guess the
    resolution is really TICK_NSEC, as it's the resolution at which we
    maintain the timer value. Thomas's patch now changes this and we keep a
    nsec value, but doesn't that mean the resolution of the timer becomes 1
    nsec? It's basically the same question as above, is the timer resolution
    the precision at which we maintain the values, the precision with which
    the timer can be read or the precision with which the timer can be

    The spec is not really clear and Thomas refusal to explain his design
    decision is as also not really helpful. :-(
    He sets the timer resolution to (NSEC_PER_SEC/HZ) which matches no value
    above and this way he basically creates another virtual timer, which has
    only little to do with the real kernel timer tick.

    I'm open to other interpretations and I think it's important to get to
    some agreement, _before_ we start to change interfaces.

    bye, Roman
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-10-16 18:38    [W:0.026 / U:1.760 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site