[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Kernel printk timestamps and walltime drift
On 13/6/08 19:49, "Roger Cruz" <rcruz@xxxxxxxxxxxxxxxxxxxxxxxx> 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |