Messages in this thread | | | Date | Fri, 24 Mar 2000 12:18:23 -0600 | From | Boris Okun <> | Subject | gettimeofday nonmonotnic with NTP |
| |
I wrote most of this before - mostly in the form of questions, but I have not got any response, so here I come again. (All this is on P2/400 2.3.99-pre2 UP)
1) gettimeofday is nonmonotonic with NTP in the presence of lost_ticks, (and probably without them, but it's much harder to trigger). The reason is that the calculation of delay at the interrupt assumes that the tick has constant value 10000usec but in reality it is a variable, changing by NTP. I can easily see backward jumps of gettimeofday of order of 100usec if I force lost_ticks to be 10 (see 4) below about lost_ticks).
2) Another side effect of this is that ntp does not work - the local time does not converge to the servers' time. NTP uses gettimeofday to calculate offsets, and gettimeofday returns wrong time.
3) There is now easy way to fix this with the current design.
4) I am unable to force lost_ticks to be >1 by doing normal stuff. So to get lost_ticks >10 I put " if( lost_ticks > 10){}" around update_times.
5) The process accounting seems to be wrong in UP. We attribute all lost ticks to the current process. On SMP we do the right thing, since we call it from interrupt handler.
6) Why do we bother to do update_times in the bottom half? We do slow reading of the timer counter and lots of other stuff at the interrupt, but the fast update_times in the bottom. What's the idea? Putting update times back to interrupt handler will remove lost_ticks, and simplify the code considerably.
Boris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |