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

[George Anzinger]

Roman Zippel wrote:
> Hi,
>
> On Wed, 14 Dec 2005, George Anzinger wrote:
>
>
> > > > 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.
> > >
> > >
> > > If the result is relative, why should have a clock set any effect?
> > > IMO the spec makes it quite clear that initial timer and the periodic timer
> > > are two different types of the timer. The initial timer only specifies how
> > > the periodic timer is started and the periodic timer itself is a "relative
> > > time service".
> >
> > Well, I guess we will have to agree to disagree.
>
>
> That's easy for you to say. :)
> You don't think the current behaviour is wrong.
On of the issues I see with using your assumption is that moving the 
timer to an absolute clock after the initial expiry _may_ lead to 
additional qauntization errors, depending on how aligned the two 
clocks are.

> > That which the interval is
> > added to is an absolute time, so I, and others, take the result as absolute.
> > At this point there really is no "conversion" to an absolute timer.  Once the
> > timer initial time is absolute, everything derived from it, i.e. all intervals
> > added to it, must be absolute.
>
>
> With this argumentation, any relative timer could be treated this way, you 
> have to base a relative timer on something.
> While searching for more information I found the NetBSD code and they 
> do exactly this, they just convert everything to absolute values and clock 
> set affects all timers equally. Is this now more correct?
I would guess, then, that either the non-absolute or the absolute 
timer behaves badly in the face of clock setting.  Could you provide a 
pointer to the NetBSD code so I can have a look too?
> > For what its worth, I do think that the standards folks could have done a bit
> > better here.  I, for example, would have liked to have seen a discussion about
> > what to do with overrun in the face of clock setting.
>
>
> Maybe they thought it wouldn't be necessary :), because a periodic is a 
> relative timer and thus not affected...

Well, then they could have said that :)  Might have prevented a lot of 
lkml bandwidth usage as well as several days of my time trying to do 
something other than what they might say is the right thing.

--
George Anzinger   george@xxxxxxxxxx
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
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/