[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] PV guest timings
On mer, 2013-11-27 at 13:00 +0000, Simon Martin wrote: ------ Original Message ------ > From: "Dario Faggioli" <dario.faggioli@xxxxxxxxxx> > > > > > 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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |