On Thu, Apr 1, 2010 at 9:34 UTC, Dreamy <[email protected]> wrote: > And maybe here comes the reason of "popular" error messages almost > every XEN-admin met: "clocksource/0: Time went backwards..." - it > looks like XEN-patched kernel generates funny switchback time?
FreeBSD had a similarly "popular" warning for a while. I'm not sure if the warning has gone away or it's simply much harder to trigger in more recent code. I'm responsible for adding a similar warning to the Windows port of ntpd, when its synthesis of the low-resolution system clock and QueryPerformanceCounter() estimates the current time as earlier than an earlier estimate. In that case, because other programs see only the low-resolution system clock, it's more of a risk to network NTP clients and perfectly ignorable if it's rare enough and/or small enough. For that reason, ntpd 4.2.7 on Windows was recently changed to suppress logging "time went backwards"-type messages in cases where the step backwards was less than 10 microseconds. The fastest network exchanges I see are tens of microseconds (more often 100-150) so that seems like a relatively conservative threshold, and in practice I have nearly always seen it report backward steps of less than 10 microseconds in routine operation. > The second question that comes to my mind > then is - why kernel uses different algo for clock and why isn't it > fixed yet? %) I was unsuccessful at jogging the right combination of memory and search-fu to dig up the source of my unreliable recollection. Your best bet to get that question settled is to post it to comp.protocols.time.ntp or its evil twin [email protected]. That is likely the source of my information. You might want to save a snapshot of the offset graph as it is now somewhere: it shows the pathological overcorrection swings, the step of the clock causing the amplitude reduction and phase change of the offset graph, and finally the result when the ntpd clock discipline loop takes over for the misbehaving kernel clock discipline loop. Hopefully that graph will jog the memory of someone who has more information on how to fix the mismatch. My untrustworthy memory suggests the four-fold difference of opinion in how to calculate an interval from a biased power of two exponent may be related to a ntpd built for "nanokernel" operation but run against a "microkernel", or vice-versa. In this context "microkernel" means "OS kernel which supports the NTP kernel loop discipline and operates in microsecond units" and similarly "nanokernel" and nanosecond units. These are the two major revisions of the interface between ntpd and a kernel with a ntpd-compatible clock discipline loop. If my memory is correct, and you are running ntpd that was not built on the host running it, rebuilding from source (such as a download from http://archive.ntp.org/ntp4/ ) would presumably fix it by building a ntpd that matches your style of kernel loop. Cheers, Dave Hart _______________________________________________ timekeepers mailing list [email protected] https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
