[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-users] Re: [Xen-devel] Domain-Virtual time


  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
  • From: Priya <pbhat@xxxxxxxxxxxx>
  • Date: Fri, 26 Feb 2010 11:46:38 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, xen-users@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 26 Feb 2010 08:48:05 -0800
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=RE84ZGpu1wMGGE68XqGAYolkhlRsN3YK2kFJ7+wclbFQ+8qqqTCf7FE68D5rBIsxU/ MdCst6VxIjzrJO63Q5xzQxKPimoG1M58D2kjVITL8Xj0vfEnilLl0iccOfyr+ebk9r8d f4u0RNUYaV8sFOxlKND/pmL6YD+c9tNy0Dvj8=
  • List-id: Xen user discussion <xen-users.lists.xensource.com>

Thanks Dan! That's a lot of useful information.

Since yesterday, I started NTP on my machines to correct and measure the amount of drift. (I am running 3 HVMs with a Ubuntu 8.04 Linux (tick-less) kernel which were all installed in an identical manner. At the time of installing the HVMs I did not change the default timer_mode).

The funny thing is that NTP is measuring a very different drift on my three machines (-189.206, -108.373 and -71.321 parts per million). The drift reported on Domain-0 is -11.393. So I don't think my machines are showing the system time.

In addition, the negative sign on the drift means that my machines are running faster that the real time, which is again puzzling. I found out that VMWare has issues with overcompensation on its linux kernels that cause the VM time to run faster. Could Xen be having a similar problem ?

The fact that all three on my machines are showing different drifts makes me doubt that they are showing the system time. I checked the CPU frequency that the three machines are reporting (from /proc/cpuinfo) and they are similar but not identical.

Any thoughts?

On Thu, Feb 25, 2010 at 3:36 PM, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
Should be "true" system time, i.e. should be very close to what
you see on a "wallclock" (clock on the wall).

HVM's are sadly very widely varied in the parameters needed
to minimize time drift.  In general in the past, timer_mode=0
(or timer_mode unspecified) would be best for 32-bit Linux
domains, timer_mode=1 would be best for Windows domains,
and timer_mode=2 would be best for 64-bit Linux domains.
However, for best results on Linux, this must be combined with
kernel boot parameters that properly select a clock -- and
on some Linux kernel versions, the parameters needed are
different between 32-bit and 64-bit versions of the same
kernel version.  It is up to providers of HVM templates
(aka "appliances") to choose parameters wisely.

Also, you haven't specified your Xen version, but I believe
Xen 4.0 switches the timer_mode default from 0 to 1 so, sadly,
clock behavior may change when moving an unchanged HVM
domain from pre-4.0 to 4.0.

So for best results you should run ntpd in any Linux HVM
domain (and I don't know what you do in Windows).  But
even ntpd may be inadequate to avoid drift if poor parameters
are chosen.

==========

From: Priya [mailto:pbhat@xxxxxxxxxxxx]
Sent: Thursday, February 25, 2010 9:04 AM
Subject: [Xen-devel] Domain-Virtual time

Sorry for multiple emails. I sent the last one from the wrong address.

Can anyone please tell me if the value returned by a time querying instruction like gettimeofday() on a Xen (Linux) HVM is the true (System) time or the Domain-virtual time?

PS: Domain virtual time is defined as the time that progresses at the same pace as cycle counter, but only while a domain is executing. It stops while the domain is de-scheduled where as System time accurately reflects the passage of real time.

I am facing issues because my HVMs show a time drift.

Thanks


_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.