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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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   [email protected]
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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux