From mboxrd@z Thu Jan  1 00:00:00 1970
From: Dario Faggioli <dario.faggioli@citrix.com>
Subject: Re: PV guest timings
Date: Thu, 28 Nov 2013 12:16:40 +0100
Message-ID: <1385637400.20797.84.camel@Abyss>
References: <em8f7250af-f445-43f0-b98a-97d1add123b2@smartin-alien>
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4262477613050033886=="
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <em8f7250af-f445-43f0-b98a-97d1add123b2@smartin-alien>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Simon Martin <smartin@milliways.cl>
Cc: Roland Heusser <heusserr@mail.gvsu.edu>, Sisu Xi <xisisu@gmail.com>, Andrew Cooper <andrew.cooper3@citrix.com>, Joshua Whitehead <whitehej@mail.gvsu.edu>, "xen-devel@lists.xen.org" <xen-devel@lists.xen.org>, Drek Darkover <wackerei@gmail.com>, Nate Studer <nate.studer@dornerworks.com>
List-Id: xen-devel@lists.xenproject.org

--===============4262477613050033886==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="=-BqBIEYoZySpqN6hHqx4a"

--=-BqBIEYoZySpqN6hHqx4a
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

> > >=20
> > Well, I think a repo somewhere would be preferrable over a tarball,=20
> > espacially if you have it in a (although private) repo already, so
> > that=20
> > we gt to see the history, the commit changelogs, etc.=20
> 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,=20
> > i.e., you print them online, store somewhere and print later/on
> > request,=20
> > etc. (I guess I could have specified this more clearly, sorry about=20
> > that :-) )=20
> 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>
> =20
> timeofday=3D12:56:41 - 1000
> 1043,47287,955121,2001800
> timeofday=3D12:56:42 - 1000
> 1024,30989,970082,2000885
> timeofday=3D12: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=20
> > values/ranges you get by measuring both are related, i.e., not=20
> > completely independent, right? Again, I'm not saying it's not useful
> > to=20
> > have both, just trying to double check I understood what you're
> > doing.=20
> 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=3Dt0+T,

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

 period: p1=3Dt0+T-t0=3DT,
 latency: l1=3Dt1-t1=3D0.

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

 t1'=3Dt0+T+l1,

that means

 latency: t1'-t1=3Dt0+T+l1-t0-T=3Dl1,

and that also makes the distance between the two handling event

 p1'=3Dt1'-t0=3Dt0+T+l1-t0=3DT+l1.

Going further on, you get

 t2=3Dt1+T=3Dt0+T+T=3Dt0+2T
 t2'=3Dt2+l2

and thus

 p2'=3Dt2'-t1'=3Dt0+2T+l2-t0-T-l1=3DT+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

--=20
<<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)


--=-BqBIEYoZySpqN6hHqx4a
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iEYEABECAAYFAlKXJhgACgkQk4XaBE3IOsRfaQCfa+jLyS1sFtbimVQtzoPQZtMF
w5oAoJRH3u0pA2T3Yk5ms+QxNYexn9up
=SDt7
-----END PGP SIGNATURE-----

--=-BqBIEYoZySpqN6hHqx4a--


--===============4262477613050033886==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============4262477613050033886==--