Re: [Qemu-devel] [RESEND][PATCH 0/3] Fix guest time drift under heavy load.

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> >The time drift is eliminated. If there is a spike in a load time may
> >slow down, but after that it catches up (this happens only during very
> >high loads though).
> 
> How bad is time drift without it.  Under workload X, we lose N seconds 
> per Y hours and with this patch, under the same workload, we lose M 
> seconds per Y hours and N << M.

In my experience, N seconds (for any N) is typically a problem with VM
systems in general.

> I strongly, strongly doubt that you'll be eliminating drift 100%.

I do believe that the method of "virtual clock warping" can eliminate
drift 100% for all guest OSes including guests which have their own
lost-tick compensators, provided there's enough host CPU _on average_
for the guest to tick, over an appropriate averaging window.  It
should work even with guests which request a different scheme with the
Microsoft PV ops.

> If the host can awaken QEMU 1024 times a second and QEMU can deliver a 
> timer interrupt each time, there is no need for time drift fixing.
> 
> I would think that with high res timers on the host, you would have to 
> put the host under heavy load before drift began occurring.

If two guests are running at 100% CPU on a single CPU, I suspect
you'll find each QEMU instance does _not_ get to run 1024 times per
second even with high res timers.  They will behave like
non-interactive processes, running alternately with long timeslices -
so even 100 or 18 times a second won't fire.  That's a reasonable
scenario, and doesn't even require any I/O or swapping.

I've personally yet to see any VM which doesn't drift
over time periods of months (i.e. servers in VMs) unless the guest is
running some kind of regular clock sync protocol - and NTP does not
always work for them, because NTP assumes a fairly low jitter clock,
which guests on a loaded host don't always manage - see above.

-- Jamie