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.
