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]
