On Thu, Apr 20, 2006 at 03:27:21PM -0000, Jesse Off wrote:
> Thanks Lennert for taking the time to comment.
No problem, thanks to you for helping me think this through.
> > 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...
Sounds possible, especially in PIO mode. IDE and MTD (flash) are
among the 'interrupts off latency' offenders. (For this to be the
cause, the system time would have to tick slower than real time, if
it's running faster it must be something else.)
There's some nice latency tracing tools available for 2.6, although
I suppose that this is on 2.4?
> > 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,
No problem.
> but does this mean that gettimeofday() is possibly non-monotonic?
I don't think so, but I'm not 100.0001% sure.. although we're using
the same algorithm on the ixp2000 (modulo the accumulator thing since
the ixp2000 time base is a nice 75MHz), and I did some heavy testing
on that platform to make sure that time never goes backwards.
> 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?
I don't think so -- whenever we increment time-of-day by 10ms, we don't
set the time offset to zero but decrement it by 10ms (assuming HZ=100.)
So, effectively, on every time tick we transfer 10ms worth of time
(again assuming HZ=100) from the time offset counter (which is kept in
units of 1/983040 seconds) to the jiffy counter (which is kept in units
of 1/HZ seconds.)
Time would only ever appear to go backwards if we would increment the
jiffy counter by a smaller amount of time than we substract from the
time offset counter, and I think this can't happen in the proposed code
(but feel free to correct me if I'm wrong.)
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/
|