time drift on dom0

time drift on dom0

[Adam Heath]

We've got a low-domU count node(only 1).  This instance is running 2
tinderboxes, and is pushing the cpu hard.

I have just noticed a 9s drift in 12 hours in dom0(not running ntp, hadn't yet
been installed).

That seems rather high to me.  Also, while running ntp is probably good to do,
requiring it seems rather poor.  Normal hardware doesn't have such a large
drift.

(xen 2.0.1, 2.6.10)


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Anthony Liguori]

Adam Heath wrote:

>I have just noticed a 9s drift in 12 hours in dom0(not running ntp, hadn't yet
>been installed).
>  
>
I've been using Xen exclusively on one of my machines for the past 
couple of weeks and I've also noticed a time drift.  I've noticed it 
more as minutes over the course of a week.  I thought it was just my 
hardware dying...

I've seen this on 2.0.2 with 2.6.9 and 2.0.3 with 2.6.10.

Regards,

>That seems rather high to me.  Also, while running ntp is probably good to do,
>requiring it seems rather poor.  Normal hardware doesn't have such a large
>drift.
>
>(xen 2.0.1, 2.6.10)
>
>
>-------------------------------------------------------
>The SF.Net email is sponsored by: Beat the post-holiday blues
>Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
>It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/xen-devel
>
>  
>



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Adam Heath]

On Sat, 15 Jan 2005, Adam Heath wrote:

> We've got a low-domU count node(only 1).  This instance is running 2
> tinderboxes, and is pushing the cpu hard.
>
> I have just noticed a 9s drift in 12 hours in dom0(not running ntp, hadn't yet
> been installed).
>
> That seems rather high to me.  Also, while running ntp is probably good to do,
> requiring it seems rather poor.  Normal hardware doesn't have such a large
> drift.

On an individual machine, running ntp is not a big deal.

But if each instance(dom0 included) must run ntp, then that is more of a
problem.

Is it possible to link the times of the instances?


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Andi Kleen]

Anthony Liguori <anthony@codemonkey.ws> writes:

> Adam Heath wrote:
>
>>I have just noticed a 9s drift in 12 hours in dom0(not running ntp, hadn't yet
>>been installed).
>>
>>
> I've been using Xen exclusively on one of my machines for the past
> couple of weeks and I've also noticed a time drift.  I've noticed it
> more as minutes over the course of a week.  I thought it was just my
> hardware dying...
>
> I've seen this on 2.0.2 with 2.6.9 and 2.0.3 with 2.6.10.

It's probably losing some timer interrupts. The lost tick handling
in Linux is not very clever and results in drifting time.

-Andi


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Martin Maney]

On Sat, Jan 15, 2005 at 05:31:34PM -0600, Adam Heath wrote:
> On Sat, 15 Jan 2005, Adam Heath wrote:
> > I have just noticed a 9s drift in 12 hours in dom0(not running ntp, hadn't yet
> > been installed).

> But if each instance(dom0 included) must run ntp, then that is more of a
> problem.
> 
> Is it possible to link the times of the instances?

UML does something along these lines - the guests (domX: x > 1) get
their timing from the host (dom0).  But that works because the guest
kernel there is running as a user process in the host environment.  Xen
would need to invoke interdomain messaging to pass queries, which
offhand sounds more costly.

I'm unsure if I replied earlier to the list, so let me point out that
IME drifts up to 200 ppm can be found outside of Xen with contemporary
PC hardware.  That's about the same Adam's reported drift, or 4 minutes
per week.  This would all be more interesting if drift under Xen could
be compared to the same piece of hardware's drift without Xen, holding
all else as much the same as practical.

-- 
This is not the first time databases and file systems have
collided, merged, argued, and split up, and it won't be the last.
The specifics of whether you have a file system or a database
is a rather dull semantic dispute  -- Rob Pike



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Keir Fraser]

> UML does something along these lines - the guests (domX: x > 1) get
> their timing from the host (dom0).  But that works because the guest
> kernel there is running as a user process in the host environment.  Xen
> would need to invoke interdomain messaging to pass queries, which
> offhand sounds more costly.

If you run NTPD in DOM0 then all other domains will be sync'ed to
DOM0's accurate timebase. This is how we run our own machines.

> I'm unsure if I replied earlier to the list, so let me point out that
> IME drifts up to 200 ppm can be found outside of Xen with contemporary
> PC hardware.  That's about the same Adam's reported drift, or 4 minutes
> per week.  This would all be more interesting if drift under Xen could
> be compared to the same piece of hardware's drift without Xen, holding
> all else as much the same as practical.

The two main places we get drift from when not using NTP are
inaccuracy of the PIT oscillator (can easily be 100 or more ppm), and
loss of significance when we program the PIT (we can't tell it to tick
precisely at 100Hz --- the closest we can get is out be a few 10s ppm
at least IIRC).

Not much we can do about the former -- we could deal with the latter
by stretching/shrinking jiffies or by inserting leap jiffies. 

 -- Keir


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt

Re: time drift on dom0

[Martin Maney]

On Sun, Jan 16, 2005 at 09:17:58AM +0000, Keir Fraser wrote:
> If you run NTPD in DOM0 then all other domains will be sync'ed to
> DOM0's accurate timebase. This is how we run our own machines.

Excellent!  I didn't recall noticing any timing problems when I was
playing with Xen (on a machine that has since moved on to other uses,
so I don't have a working Xen testbed right now), but it was already
running NTP in the system image that became dom0.

Is this syncing what gives rise under some circumstances to the clock
moving backwards that I've seen mentioned here?  Never saw that, but I
never got around to pushing that box hard.

> The two main places we get drift from when not using NTP are
> inaccuracy of the PIT oscillator (can easily be 100 or more ppm), and

Yep.  As I say, I've seen at least a couple different machines that run
right around 200 ppm (one fast and one slow, as it happens) under
non-Xen Linux.  The frequencey correction is quite stable over the half
year or so I've been logging the NTP stats.

> Not much we can do about the former -- we could deal with the latter
> by stretching/shrinking jiffies or by inserting leap jiffies. 

Seems like a waste of effort, given errors an order of magnitude larger
than the nominal setting error.  If you want accurate time, you need to
run NTP anyway.  :-)

Or... was it adjtimex that I used to use back in the dark ages of
dialup?  Would that work to trim the dom0 clock error (it was more or
less a manual correction for drift, as I recall)?

-- 
Vs lbh pna ernq guvf, lbh'er va ivbyngvba bs
gur Qvtvgny Zvyyraavhz Pbclevtug Npg.  -- anon.



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt