lkml.org 
[lkml]   [2005]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 00/21] hrtimer - High-resolution timer subsystem
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/
-
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/

\
 
 \ /
  Last update: 2005-12-19 21:59    [W:0.117 / U:0.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site