discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] FIFO latency


From: Alexander Chemeris
Subject: Re: [Discuss-gnuradio] FIFO latency
Date: Sun, 29 May 2011 00:14:31 +0400

On Sat, May 28, 2011 at 22:50, Marcus D. Leech <address@hidden> wrote:
>> On Sat, May 28, 2011 at 22:06, Marcus D. Leech<address@hidden>  wrote:
>>>
>>> I evaluated latency of a FIFO (actually an ordinary pipe, but the kernel
>>> mechanisms are identical), and measured 30usecs average on my
>>>  1.2GHz AMD Phenom system with plenty 'o memory.
>>>
>>> I sent timestamps across the FIFO (struct timeval), and the reader
>>> grabbed
>>> the local time of day, and computed the difference.  There's
>>>  a fair amount of uncertainty on the reader due to gettimeofday() call
>>> overhead.  But 30usec on a wimpy CPU is certainly comfortably
>>>  below 1msec.
>>
>> gettimeofday() is a fast function. But if you want real high-fidelity
>> - read CPU clock counter. Just make sure your app runs on a one
>> selected core.
>>
>> Could you post your app and raw results? I'm interested in
>> min/mean/max values and distribution graphs. Because max values do
>> play role when playing with real-time.
>>
> <skip...>
> I just run it like:
>
> ./latency_writer | ./latency_reader
>

Thank you for your tests. I slightly updated your tests to make them
less dependent of printf() timing which is *very* non-realtime.

I run the test with  "chrt 80 ./run_test.sh". Mean delay is much
better then yours (mean 8.2us), but latency jumps up and down even
under RT priority. This probably can be improved, or may be not.

1) If I run 10 tests with short sampling time, I get picture data.png
(raw data is in data.txt)

2) If I do a single run with long sampling time, I get picture
data2.png (raw data is in data2.txt)

You see, that delay is far from predictable. This may be possible to
improve and may be not - file operations in usual Linux are not meant
for real-time operation.

So, while this method is simple and good for non-realtime
applications, it doesn't fit our needs. It may be usable for PHY<->MAC
interaction, but even here I'm not sure it would work well.

PS I test on Core 2 Duo 1.6 GHz with all the GUI stuff running.

-- 
Regards,
Alexander Chemeris.

Attachment: data.txt
Description: Text document

Attachment: latency_reader.c
Description: Text Data

Attachment: latency_writer.c
Description: Text Data

Attachment: run_test.sh
Description: Bourne shell script

Attachment: data.png
Description: PNG image

Attachment: data2.png
Description: PNG image

Attachment: data2.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]