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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Hi Darryl –

 

So how would a userland enterprise app go about doing this?

For example, the Oracle DB (and other Oracle enterprise apps) collects timestamps at a high frequency, sometimes more than 10K timestamps/second.  (These are used primarily for collecting transaction statistics, but these statistics are collected by default and must be explicitly disabled by a DB administrator.)   As one might expect, the difference between any two of these timestamps is the key result and the two timestamps may differ by seconds or minutes so, as  a result, the two timestamps of interest may cross a live migration boundary.

 

I am guessing that to use the approach you suggest, both the counter and some form of “generation indicator” must be stored for each timestamp, then when the difference between the two is to be calculated, the RADclock history is consulted, essentially to lookup, if they are different, the two generation indicators and use them to adjust the two counters.

 

Ideally, this would be entirely hidden from userland in the kernel, but the cost of a “real” system call is too high to be incurred 10K/sec, and I’m not sure how RADclock history could be consulted in a vsyscall.

 

Thanks,

Dan

 

P.S. Since you probably don’t closely follow the xen-devel list, some discussion has occurred on other threads without cc’ing you.  If you are interested, search for RADclock in xen.markmail.org.

 

From: Darryl Veitch [mailto:dveitch@xxxxxxxxxxxxxx]
Sent: Friday, October 15, 2010 4:57 PM
To: Dan Magenheimer
Cc: Tim Deegan; Jeremy Fitzhardinge; Jan Beulich; Hang Du; Keir Fraser; Saipu Liu; Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx; Julien Ridoux; Timothy Broomhead
Subject: Re: [Xen-devel] [PATCH] time-xen : Reset monotonic time when sync up time from dom0 to domU

 

Hi All,

 

in terms of pounding on xenstore, one way to get around this is to note that raw timestamps (that is what we call counter readings) can be taken at the required events but only converted to walltime later. This could be done in batches asynchronously, and perhaps even much later off-line, depending on the application.  This is one of the advantages of the feedforward approach. The RADclock keeps historical data which enables raw timestamps to be converted to walltime at any time with identically zero loss of precision- they would be exactly the same wallclock values as if they were calculated immediately.

 

Darryl

 

 

On 15/10/2010, at 4:53 PM, Dan Magenheimer wrote:

(RADclock authors cc'ed in attempt to re-merge the two threads...
Tim, if it's not too late, please reply to this email rather
than the previous one without the full cc list)

From: Dan Magenheimer

Sent: Friday, October 15, 2010 8:47 AM

To: Tim Deegan

Cc: Jeremy Fitzhardinge; Jan Beulich; Hang Du; Keir Fraser; Saipu Liu;

Shunli Yi; xen-devel@xxxxxxxxxxxxxxxxxxx

Subject: RE: [Xen-devel] [PATCH] time-xen : Reset monotonic time when

sync up time from dom0 to domU

 

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

 

Agreed that this is a better solution to a very important problem.

I'm just trying to determine if it helps solve another time-related

real world problem.

 

- 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.

 

Agreed that a generation counter solves this.  BUT...

 

(1) afaik there is no generation counter in any time-related

kernel API; and

 

(2) afaict this generation counter would need to be "pushed"

from the dom0 kernel so would either (a) require domU kernels

to read from xenstore, or (b) require some kind of privileged

hypercall from dom0 to the hypervisor telling the hypervisor

to change the generation counter (and scaling values?) for all

domUs.

 

-----------------------------------------------

Darryl Veitch

Sabbatical Address:

TREC INRIA

23 Avenue D'Italie

75214 Paris Cedex 13, France 

Tel:  +33 (0)1 39 63 55 40

&

Technicolor Paris Research Lab

1, rue Jeanne d'Arc

92443 Issy-les-Moulineaux Cedex, France

Tel:  +33 (0)1 41 86 52 19

 

Global:

dveitch AT unimelb edu au

http://www.cubinlab.ee.unimelb.edu.au/~darryl/

AIM id:  darrylveitch

Skype:  darrylveitch

 

 

 

 

 

 

 

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