Calculating latency using high resolution timer

Calculating latency using high resolution timer

[Sarin, Suseelan]

Hi All,

My real-time program has a thread which needs to run at every 2ms. I
want to calculate the latency of this thread and I am using
clock_gettime for this. I am bit confused here that whether I can do
this. My doubt is, if the system is loaded to the extend that an RT
task can have considerable latency, can I trust the time read from the
high resolution timer of the system?

Also, with these measurements, I am seeing a ~5msec latency. Is there
a way I can exactly point out the reason for this latency?

Thanks in advance.

Regards,
Sarin

Re: Calculating latency using high resolution timer

[Thomas Gleixner]

On Wed, 9 Jun 2010, Sarin, Suseelan wrote:

> Hi All,
> 
> My real-time program has a thread which needs to run at every 2ms. I
> want to calculate the latency of this thread and I am using
> clock_gettime for this. I am bit confused here that whether I can do
> this. My doubt is, if the system is loaded to the extend that an RT
> task can have considerable latency, can I trust the time read from the
> high resolution timer of the system?

Yes, it's accurate. cyclictest relies on that as well.

> Also, with these measurements, I am seeing a ~5msec latency. Is there
> a way I can exactly point out the reason for this latency?

Tracing. See cyclictest.c for how that's done.

Thanks,

	tglx

Re: Calculating latency using high resolution timer

[Sarin, Suseelan]

>> this. My doubt is, if the system is loaded to the extend that an RT
>> task can have considerable latency, can I trust the time read from the
>> high resolution timer of the system?
>
> Yes, it's accurate. cyclictest relies on that as well.
>
>> Also, with these measurements, I am seeing a ~5msec latency. Is there
>> a way I can exactly point out the reason for this latency?
>
> Tracing. See cyclictest.c for how that's done.

Thank you. I will check the cyclic test code and get back.

Re: Calculating latency using high resolution timer

[Sarin, Suseelan]

>
> Not a lot of information about your test (kernel version, kernel config, -rt patch, your code, etc) in your mail, but I would expect a 2 millisecond deadline to be easy to meet.  At 5 milliseconds, I'd say you aren't using RT scheduling at all.
>

Thank you for the response and for the code. I haven't seen your code
in detail, but will do that soon. I am running 2.6.29 with board
specific patches and patched with 2.6.29-rt3. ARMv5 running at about
700 bogo-mips. When the system is completely in use, the CPU usage
goes and stays at 99%+ for most of the time.

> The output below is from a pretty crude/simple chunk of test code that was run on kernel 2.6.26.8-rt16 (yes, it's old, but it's a box thats up and reachable by me right now). Times are in microseconds.  The code sleeps for 100 microseconds, then checks how long it actually slept, outputting some stats once a second.
>
> crappy test code is at:
> http://www.rato.us/ltest.c
> Compile with "gcc ltest.c -lrt -oltest".
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html