Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

At 15:09 +0100 on 15 Oct (1287155382), Dan Magenheimer wrote:
> > At 17:48 +0100 on 13 Oct (1286992083), Jeremy Fitzhardinge wrote:
> > > > There was a paper about this at OSDI last week:
> > > > http://www.usenix.org/events/osdi10/tech/full_papers/Broomhead.pdf
> > >
> > > Ooh, look, RADclock, just what I was thinking about.
> > 
> > Yes, it looks pretty good.  Also they can use Xen stime as the local
> > oscillator and distribute drift numbers from xenstore, so no hypervisor
> > patches (and no hypervisor-interface changes) required. :)
> 
> Maybe I'm misunderstanding the paper, but isn't it required
> that Xen stime be directly readable for every attempt to
> sample time (e.g. requiring at least some small interface
> change such as adding a hypercall to obtain Xen stime)?

You can obtain xen stime directly from the shared-into page and RDTSC.
There might need to be _kernel_ changes to make that available to
userspace, though my impression is that they push packet-timestamping
into the kernel.

> Also, for those certain enterprise applications that want
> to sample time 10000+ samples/second/processor, and need
> to know "immediately" when a sample might be bad (due
> to, for example, live migration), I think each sample would
> need to check xenstore.  Is xenstore up to that kind of
> pounding (and is it fast enough)?

No it's certainly not (either of those things), but:
 - the problem of turning a distributed wallclock into something suitable
   for timestamping that aggressively is orthogonal to the problem of
   distributing that wallclock in the first place; and
 - all the user really needs is a generation counter to know that the 
   clock correction values are stale, and the kernel can provide that 
   alongside the stime.

Cheers,

Tim.

-- 
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, XenServer Engineering
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

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