Re: PV guest timings

[Dario Faggioli <dario.faggioli@citrix.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3684 bytes --]

On mer, 2013-11-27 at 13:00 +0000, Simon Martin wrote:
 ------ Original Message ------
> From: "Dario Faggioli" <dario.faggioli@citrix.com>

> > > 
> > Well, I think a repo somewhere would be preferrable over a tarball, 
> > espacially if you have it in a (although private) repo already, so
> > that 
> > we gt to see the history, the commit changelogs, etc. 
> Here's the URL. https://github.com/FurryFuttock/micro-pv. There is no
> commit history as I mostly use SVN. I just created this and will keep
> it up to date as I carry on playing with it.
>
Once more, thanks for this. It looks really interesting and, if you ask
me, I'll sure it will be useful!

I took a quick look at it, and added to my TODO list to properly look
into it. Hopefully, it won't take that long. :-)

> > Sure, that part I got. I was more asking how you get these numbers
> > out, 
> > i.e., you print them online, store somewhere and print later/on
> > request, 
> > etc. (I guess I could have specified this more clearly, sorry about 
> > that :-) ) 
> Here's an example. There are 2 lines per sample. Line 0 has format
> <time> <ticks per second>, line 1 has <latency min/max>,<period
> min/max>
>  
> timeofday=12:56:41 - 1000
> 1043,47287,955121,2001800
> timeofday=12:56:42 - 1000
> 1024,30989,970082,2000885
> timeofday=12:56:43 - 1000
> 1042,30888,970167,2000947
> ...
>
Ok, I was wondering whether, e.g., the printing could interfere with the
measurements, and stuff like that, but I checked this out in your code,
and it doesn't look like it is happening.

> > Ok, I think I see now. Just to confirm that I do, this means that
> > the 
> > values/ranges you get by measuring both are related, i.e., not 
> > completely independent, right? Again, I'm not saying it's not useful
> > to 
> > have both, just trying to double check I understood what you're
> > doing. 
> They're not really related. Period is time between events, Latency is
> time from event to handler.
>
"Period is time between events", what events? I was thinking the events
to be two subsequent invocation of the handler. In an ideal world, that
would be exactly equal to the PERIOD that you choose, which also mean
latency would be 0. OTOH, if you get some latency in invoking the
handler, you'll see different values for the actual time difference
between different invocations... Otherwise, how could period vary over
time?

I mean, if at t0 you set the next event to occur at

 t1=t0+T,

still in the ideal world, you'll get the event both triggered and
handled exactly at t1, i.e.,

 period: p1=t0+T-t0=T,
 latency: l1=t1-t1=0.

If, OTOH, you get some latency, i.e., you are processing the event in
the handler at

 t1'=t0+T+l1,

that means

 latency: t1'-t1=t0+T+l1-t0-T=l1,

and that also makes the distance between the two handling event

 p1'=t1'-t0=t0+T+l1-t0=T+l1.

Going further on, you get

 t2=t1+T=t0+T+T=t0+2T
 t2'=t2+l2

and thus

 p2'=t2'-t1'=t0+2T+l2-t0-T-l1=T+l2-l1

That's what I meant with "related".

Checking the code (but very quickly, so bear with me if I'm getting
something wrong), _BUT_, I totally understand that this relationship is
only useful if you perform the calculation a bit differently, and the
way you're doing them allows you to monitor both latency and jitter good
enough anyway, so I'm cool with it. :-)

Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel