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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:13 EST