# Re: [Xen-devel] PV guest timings

 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. Thanks. All feedback is welcome.         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. It shouldn't. I calculate numbers in the periodic interrupt and then print them from the normal run loop.      > 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? As you say, events in this context are subsequent invocations 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? Not quite. Let us say that latency is always 5 Âs, no jitter. That means that the measured period will always be exactly the same, just slightly delayed in time. This is fine.   However there IS jitter in the latency (+/- 30 Âs) so the period varies likewise. One event comes in late, the next comes in on time, period is less than expected. One comes in on time the next comes in late, period is longer than expected.     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". I agree, it is not a direct relationship, but yes they are 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. I'm glad I haven't got it too wrong at the first attempt.

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

 Lists.xenproject.org is hosted with RackSpace, monitoring our servers 24x7x365 and backed by RackSpace's Fanatical Support®.