Messages in this thread | | | Date | Wed, 21 Mar 2001 16:14:40 -0600 | From | Eli Carter <> | Subject | Re: gettimeofday question |
| |
Russell King wrote: > > Eli Carter writes: > > What are you seeing that I'm missing? > > Ok, after sitting down and thinking again about this problem, its not > the 9.9999ms case, but the 10.000000001 case: [snip] > Like I say, this requires good timing to create, so may not be too much of > a problem, but it does seem to be a problem that could occur.
It appears that this problem is easier to create than we originally gave credit for.... All that is needed is for gettimeoffset() not to be called for a _minimum_ of >10ms, and for the timer to wrap during a call to do_gettimeofday() or during a period of time where interrupts are disabled and do_gettimeofday() is called. Note that there is no upper limit to the time...
If we call gettimeoffset() after do_timer() returns (and there-by update the internal variables every 10ms), we should reduce the impact of this bug dramatically (in theory--in practice, disabling interrupts for long periods can also have some bad effects that this won't help, but I think that's another issue.)
One of the guys I'm working with did some testing on this, and he was seeing this problem (off by 10ms) every 5 to 10 minutes (on a modified ARM & kernel). With the additional gettimeoffset() call, he no longer saw it (at least within ~3hrs.).
Questions, comments, etc.?
Eli -----------------------. Rule of Accuracy: When working toward Eli Carter | the solution of a problem, it always eli.carter(at)inet.com `------------------ helps if you know the answer. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |