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

[George Anzinger <george@mvista.com>]

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@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/