Xen project Mailing List

Quote:

tsc is part of your actual CPU. I don't know what tsc was really meant for when designed, but it's a poor choice for timer when time
accuracy is important, because, well, it's simply not accurate. When my system was using tsc, I would notice time drift of almost 1
minute every hour. This seems to be considered 'ok' by people because you can just configure your computer to adjust clock daily with
ntp. Asside from the problem that tsc time will drift depending on your system load, if you have a multi-core system, tsc will drift
from itself on different cores. Some multi-core cpu's will synchronize tsc (I think the Intel Core 2 series, for example, but don't
quote me),, whereas other CPU's will lead to tsc being unstable and the system switching to something else. (although, this should
all happen automagically, a system throwing a hairball over it should be considered a bug.)

Quote2:

The time stamp counter has, until recently, been an excellent
high-resolution, low-overhead way of getting CPU timing information.
With the advent of multi-core/hyperthreaded CPUs, systems with multiple
CPUs, and "hibernating" operating systems, the TSC cannot be relied on
to provide accurate results — unless great care is taken to correct the
possible flaws: rate of tick and whether all cores (processors) have
identical values in their time-keeping registers. There is no promise
that the timestamp counters of multiple CPUs on a single motherboard
will be synchronized. In such cases, programmers can only get reliable
results by locking their code to a single CPU. Even then, the CPU speed
may change due to power-saving measures taken by the OS or BIOS, or the
system may be hibernated and later resumed (resetting the time stamp
counter). In those latter cases, to stay relevant, the counter must be
recalibrated periodically (according to the time resolution your
application requires).

Quote3:

Quoting from the same article some modern CPUs also provide a constant
Time Stamp Counter: Recent Intel processors include a constant rate TSC
(identified by the constant_tsc flag in Linux's /proc/cpuinfo). With
these processors, the TSC reads at the processor's maximum rate
regardless of the actual CPU running rate.

My 2 cents:

https://wiki.debian.org/Xen/Clocksource

It depends on your setup I think. DomU's Dom0...

I have had huge issues with proxmox (kvm I know, but an example of virtualization) and some BSD guests.

Never had much issue with xen but it has been a while since I have installed a dom0 from scratch...

It looks like you can adjust your clock source settings like so: https://wiki.xen.org/wiki/Xen_power_management#Xen_hypervisor_clocksource_option

I do not know if that is still relevant but if you are having time went backwards messages...usually something is up. With proxmox I had to disable all powersaving...this was a hybrid project with a virtualized router and some other stuff ran on a portable laptop though.

On Fri, Feb 10, 2017 at 9:18 AM, Iain Buchanan <iainbuc@xxxxxxxxx> wrote:
>
> Hi,
>
> I'm trying to determine how accurate the clock is on a Xen guest (running on AWS). I hadn't realised how complex virtualising clocks were until I started looking into this!
>
> I have a few questions around clocksource settings I hope someone can help me with:
>
> - I get the impression that the "tsc" clocksource in Xen is relatively recent, and should bring the guest and host clocks in line, but I could not determine how often this synchronisation takes place or if there are any bounds on clock drift?
>
> - The default (using an Ubuntu 14.04 image at least) under AWS seems to be the "xen" clocksource. From messages online this appears to be able to go backwards, which suggests that it is also forcing the guest to be in line with the host. Is this the case?
>
> Iain
>
> _______________________________________________
> Xen-users mailing list
> Xen-users@xxxxxxxxxxxxx
> https://lists.xen.org/xen-users

Re: [Xen-users] Clock accuracy