George,I think the standard was written to eliminate the need for this. The notion is that we have a resolution which we use in the calculations so while there may be drift WRT his request, there should be no drift WRT the requested value rounded up to the next resolution.
On Fri, 2005-08-19 at 17:19 -0700, George Anzinger wrote:
2. Drift of cyclic timers (armed by set_timer()):
Due to rounding errors and the drift adjustment code, the fixed
increment which is precalculated when the timer is set up and added on
rearm, I see creeping deviation from the timeline.
I have a patch lined up to base the rearm on human (nsac) units, so this
effect will go away. But this is waste of time until (1.) is not solved.
George ???
Could I (we) see what you have in mind?
Nothing which applies clean at the moment and I have no access to the
box where the patch floats around.
It's simply explained.
Current code:
set_timer()
calc interval->jiffies / interval->arch_cycles;
based on it.interval
rearm()
timer->expires += interval->jiffies;
timer->arch_cycle_expires += interval->arch_cycles;
normalize(timer);
Patched code:
set_timer()
timer.interval = it.interval; timer.next_expire = it.value; both stored as timespec
rearm()
next_expire += interval;
calc timer->expires/arch_cycle_expires;
So on each rearm we eliminate the rounding errors and take the drift
adjustment into account.
It adds some calculation overhead to each rearm, but ....