Re: Keeping time in guest domains

[Greg Troxel <gdt%ir.bbn.com@localhost>]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:

> On Sat, Dec 10, 2005 at 04:14:29AM +0100, Hubert Feyrer wrote:
> > On Sat, 10 Dec 2005, Johnny C. Lam wrote:
> > >What's the right way to keep the right time in guest domains?  I'm
> > 
> > Maybe this helps:
> > http://mail-index.netbsd.org/tech-kern/2005/12/07/0001.html
> > ?
> 
> Yes, this will probably help a bit. There is MD code in Xen trying
> to achieve this without patching MI files, but it may not be
> completely right.  Because of domain scheduling, the clock
> interrupts as seen by domains may not be perfectly stable.

Even if so, they won't result in the right time.  In a non-buggy real
system, the clock interrupts have some nominal period, and the actual
period will be close to the nominal, perhaps within 100 ppm, due to
deviations of the crystal from the design frequency.  The error will
vary by a few ppm over a day or so, mostly tracking thermal changes.
NTP runs and estimates a drift rate to cause the resulting rate of
time advance to be correct.  (On my laptop about 17 ppm of advance is
needed.)  NTP running in dom0 will estimate and correct for this, and
the domUs should each see the same fundamental oscillator rate.  So
they'd each need the same drift rate.

I just checked a machine I have set up (vanilla P4, Intel 845
chipset):

dom0 ntpdc -c loopinfo:
offset:               -0.000757 s
frequency:            9.813 ppm
poll adjust:          30
watchdog timer:       1744 s

domU
offset:               -0.000863 s
frequency:            9.842 ppm
poll adjust:          30
watchdog timer:       2532 s

The frequency errors are remarkably close; 0.029 ppm, which seems
within noise.  Both the dom0 and domU are running ntpd to the same set
of peers.  This was "obviously" the right thing to do from my
viewpoint, but migth well not be.

On another xen box up 5 days 4h12, dom0 is ntp synced, and two domUs
not running ntp are now 18 and 12 seconds behind.  This doesn't
surprise me much, although the relative error is significant.  So
there are perhaps some interrupt issues as well - which ntp will
smooth over.

-- 
        Greg Troxel <gdt%ir.bbn.com@localhost>