On Thu, Apr 20, 2006 at 12:22:14AM -0000, Jesse Off wrote:
> This is great Lennert! Thanks for looking into this!
No problem!
> At first glance it seems you skip calling timer_tick() every once in
> awhile to fix the accumulated error.
Indeed.
We round down when dividing 504468.9 by HZ, which means that the timer
interrupt always gets called slightly more often than HZ times per
second, which means we generally do not ever have to do two timer_tick()s
in a single timer interrupt -- but we do use a while () instead of an
if () because we don't want to lose any timer ticks when people keep
interrupts disabled for longer than 10ms (no idea why, but people
do this kind of stuff, and then complain that their clock is wrong..
d'oh.)
> Can you comment on how (if at all) this might effect worst case
> process and timer event scheduling
Since we generally never call timer_tick() twice per timer interrupt
(except when people keep interrupts masked for too long, see above),
userland and kernel timers will not sleep for a shorter duration than
what they asked for.
Sometimes a process might end up sleeping too long (if it decides to
sleep for 0.0001 second just moments before a timer interrupt comes in,
and that timer interrupt decides to skip calling timer_tick()), but it
is already the case that processes can sleep arbitrary amounts of time
longer than what they asked for, as nanosleep(x) is documented as
sleeping for "at least x".
> and small interval event timing now that theres a potential ~2x longer
> clock period every so often. Specifically, if I'm measuring time
> between two points A and B around 1.45 seconds or so(*) and happen to
> experience the skipped clock tick in-between, would I randomly be
> missing approx 10 ms of real time in my difference calculation?
Nope -- gettimeofday() will always return 'the right time'. The
'current time' in us is (1000000 * number_of_jiffies_since_boot / HZ)
plus whatever gettimeoffset() returns at the particular moment. As I
wrote, gettimeoffset() is implemented as:
static unsigned long ep93xx_gettimeoffset(void)
{
int offset;
offset = __raw_readl(EP93XX_TIMER4_VALUE_LOW) - last_jiffy_time;
/* Calculate (1000000 / 983040) * offset. */
return offset + (53 * offset / 3072);
}
I.e. it returns the number of us since 'last_jiffy_time'. Now, note
how the timer interrupt only calls timer_tick() (which increments
number_of_jiffies_since_boot) whenever it increments last_jiffy_time
by 983040 / HZ. If it doesn't call timer_tick(), it won't increment
last_jiffy_time either, which then means that gettimeoffset() will
return values > 1000000 / HZ for a while until the next timer interrupt
comes in.
(I hope this concludes the proof :-)
cheers,
Lennert
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|