From mboxrd@z Thu Jan 1 00:00:00 1970 From: Priya Subject: Re: [Xen-devel] Domain-Virtual time Date: Fri, 26 Feb 2010 11:46:38 -0500 Message-ID: <5c3550fe1002260846s6775ac4dsabf90bba503d7b@mail.gmail.com> References: <5c3550fe1002250803q21decea2j101c53fe390b856c@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1190059599==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-users-bounces@lists.xensource.com Errors-To: xen-users-bounces@lists.xensource.com To: Dan Magenheimer Cc: xen-devel@lists.xensource.com, xen-users@lists.xensource.com List-Id: xen-devel@lists.xenproject.org --===============1190059599== Content-Type: multipart/alternative; boundary=00504502cdebb124f3048083a4ae --00504502cdebb124f3048083a4ae Content-Type: text/plain; charset=ISO-8859-1 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 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@acis.ufl.edu] > Sent: Thursday, February 25, 2010 9:04 AM > To: xen-devel@lists.xensource.com; xen-users@lists.xensource.com > 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 > > --00504502cdebb124f3048083a4ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 t= hree 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 show= ing 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 mak= es me doubt that they are showing the system time. I checked the CPU freque= ncy 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@oracle.com> 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. =A0In general in the past, timer_mode=3D0
(or timer_mode unspecified) would be best for 32-bit Linux
domains, timer_mode=3D1 would be best for Windows domains,
and timer_mode=3D2 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. =A0It 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). =A0But
even ntpd may be inadequate to avoid drift if poor parameters
are chosen.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

From: Priya [mailto:pbhat@acis.ufl.ed= u]
Sent: Thursday, February 25, 2010 9:04 AM
To: xen-= devel@lists.xensource.com; xen-users@lists.xensource.com
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 instruct= ion like gettimeofday() on a Xen (Linux) HVM is the true (System) time or t= he 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 pa= ssage of real time.

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

Thanks


--00504502cdebb124f3048083a4ae-- --===============1190059599== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users --===============1190059599==--