lkml.org 
[lkml]   [2000]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: gettimeofday nonmonotnic with NTP
On Fri, Mar 24, 2000 at 12:18:23PM -0600, Boris Okun wrote:
> 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.


I'm running a patch on one of my computers right now that introduces a
new design for kernel timekeeping. Right now, one of the main problems
is that we use the 8253 counter 0 for coarse timing, and the TSC for
fine timing -- keeping the two accurately synchronized is not easy, and
probably not possible in practice using the current method.

The patch I've written modularizes the timers, and eliminates the counter
0 dependency. It also makes lost_ticks irrelevant. I'd like to use a
ntp-like PLL to synchronize the TSC to the 8253 timer in the case where
there is no external timing source. Synchronizing to the RTC is another
good option.

The patch is a little bit rough right now, since it doesn't synchronize
to anything, thus the kernel time diverges due to the inaccuracy of cpu_hz.
It's obviously not a 2.4 thing, but I'd like to see it added to 2.5.
Right now, I either need to learn more about NTP, or find an NTP expert.




dave...


-
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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.292 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site