Re: [patch 00/21] hrtimer - High-resolution timer subsystem



On Mon, 2005-12-12 at 17:25 -0800, George Anzinger wrote:
> >>The rationale for example talks about "a periodic timer with an absolute
> >>_initial_ expiration time", so I could also construct a valid example with
> >>this expectation. The more I read the spec the more I think the current
> >>behaviour is not correct, e.g. that ABS_TIME is only relevant for
> >>it_value.
> >>So I'm interested in specific interpretations of the spec which support
> >>the current behaviour.
>
> My $0.02 worth: It is clear (from the standard) that the initial time
> is to be ABS_TIME. It is also clear that the interval is to be added
> to that time. IMHO then, the result should have the same property,
> i.e. ABS_TIME. Sort of like adding an offset to a relative address.
> The result is still relative.

So the only difference between a timer with ABSTIME set and one without
is the notion of the initial expiry value, aside the
clock_settime(CLOCK_REALTIME) speciality.

ABSTIME:
firstexp = it_value
firstexp, firstexp + it_interval, ... firstexp + n * it_interval

non ABSTIME:
firstexp = now + it_value
firstexp, firstexp + it_interval, ... firstexp + n * it_interval

The only limitation of this is that the interval value can not be less
than the resolution of the clock in order to avoid the wrong accounting
of the overflow.

> > Unfortunately you find just the spec all over the place. I fear we have
> > to find and agree on an interpretation ourself.
> >
> > I agree, that the restriction to the initial it_value is definitely
> > something you can read out of the spec. But it does not make a lot of
> > sense for me. Also the restriction to TIMER_ABSTIME is somehow strange
> > as it converts an CLOCK_REALTIME timer to a CLOCK_MONOTONIC timer. I
> > never understood the rationale behind that.
>
> I don't think it really does that. The TIMER_ABSTIME flag just says
> that the time requested is to be taken as "clock" time (which ever
> clock) AND that this is to be the expire time regardless of clock
> setting. We, in an attempt to simplify the lists, convert the expire
> time into some common time notation (in most cases we convert relative
> times to absolute times) but this introduces problems because the
> caller has _asked_ for a relative or absolute time and not the other.
> If the clock can not be set this is not a problem. If it can, well,
> we need to keep track of what the caller wanted, absolute or relative.
>
> It might help others to understand this if you were to remove the
> clock names from your queues and instead call them "absolute_real" and
> "up_time". Then it would be more clear, I think, that we are mapping
> user requests onto these queues based on the desired functionality
> without a predilection to put a timer on a given queue just because a
> particular clock was requested. At this point it becomes clear, for
> example, that a TIMER_ABSTIME request on the real clock is the _only_
> request that should be mapped to the "absolute_real" list.

In other words. If there is only CLOCK_REALTIME, then the implementation
has to keep track of absolute and relative timers.

The existance of CLOCK_MONOTONIC and the fact that CLOCK_MONOTONIC is
using the same clock source as CLOCK_REALTIME allows us to optimize the
implementation by putting the relative timers on the monotonic list.

tglx


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: AMD to integrate PCIe into CPU
    ... >>>overhead in encoding parallel data into serial data, embedding clock ... Yeah the spec is better but looooong and I'm lazy and not able to see PCIe ... >The real latency difference comes in error control. ... >skew and tolerance at the board level. ...
    (comp.sys.ibm.pc.hardware.chips)
  • Re: Using (various stuff) to expand PIC outputs
    ... be if it used differential signaling. ... line each for signal, shift clock, and latch clock? ... your spec NOW or you'll likely get bitten in the ass. ... The aforementioned signal concerns, conservative design, and a potential ...
    (sci.electronics.design)
  • Re: Using (various stuff) to expand PIC outputs
    ... line each for signal, shift clock, and latch clock? ... your spec NOW or you'll likely get bitten in the ass. ... You need to stop and think hard and *define* your required maximum data rate. ... to design kit without a defined spec is a mug's game. ...
    (sci.electronics.design)
  • Re: Debian Sarge: Intermittent random crashes
    ... Clock it down. ... The CPU and M/B temps are within normal range, and I assume you're not suggesting running that way, any more than you would ... I don't disagree that this is almost certainly hardware, but even if the system runs stable at below spec speed I'm not ture it helps fix the problem. ...
    (comp.os.linux.setup)
  • Re: fooled by shifting date
    ... tight loop and store the corresponding [clock clicks] value at that moment. ... Use that to compute millisecond values for statements to have the ... after statement excecute on a certain second boundary 11:30:00 ... absolute times in 8.4. ...
    (comp.lang.tcl)