Re: Kernel printk timestamps and walltime drift

[Keir Fraser <keir.fraser@eu.citrix.com>]

On 13/6/08 19:49, "Roger Cruz" <rcruz@marathontechnologies.com> wrote:

> You can see that the kernel time in the brackets (host up time in
> seconds) should have given us a difference of 3600 seconds when ran over
> an hr period. I, however, got 3592.770286, a slip of  7+ seconds.  I've
> ran a similar experiment and over the course of 12hrs, the kernel
> timestamps lose 97 seconds!
> 
> So unless I'm misunderstanding the printk times, the problem is either
> with the way the Linux OS converts TSC cycles to seconds not being very
> accurate  OR how the hypervisor feeds the VM-ified TSC counts to the
> guest VM. 
> 
> Note that I'm sure the walltime was correct as I could monitor the
> printed walltime against an atomic clock in another window and it always
> matched (within the precision of my eyes moving back and forth, of
> course).

Do you know how the Debian kernel is computing its kernel-log timestamps?

One possibility here is that Xen system time is running at a slightly
different rate from wallclock (because the platform timer (PIT, HPET, etc)
is not running at exactly its stated frequency) and ntp running in dom0 only
keeps Xen's wallclock reference in sync -- it does not affect Xen's system
time. If the Debian kernel were perhaps based on jiffies rather than xtime,
I think that might explain the drift.

This hypothesis would require Xen's system time to be drifting at around
2000ppm, which is not great. I would expect a platform timer to be within a
few 100ppm of its advertised frequency, really (and with jitter of much less
than 10ppm).

 -- Keir