Thanks Lennert for taking the time to comment.
> 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.)
Interesting. I have had discussions with another customer about the
serial port overflowing due to missed serial intrs. His working
theory was that the IDE driver was the culprit. If his theory is
correct, perhaps this might explain some of the time drift on a TS-
7200...
> 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 :-)
Sorry to drag this on, but does this mean that gettimeofday() is
possibly non-monotonic? Since gettimeoffset() can return values
greater than a tick period, but a tick period only increments time-
of-day by a hard 10mS would it not be possible for 2 consecutive
gettimeofday() readings to go backwards by <=10mS?
//Jesse Off
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/
|