Re: [Discuss-gnuradio] FIFO latency

[Alexander Chemeris]

On Sun, May 29, 2011 at 00:14, Alexander Chemeris
<address@hidden> wrote:
> 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.

Ok, setting CPU affinity and cutting off startup artifacts definitely helps.
Results are in attachment.
Still you can see quite some uncertainty.

-- 
Regards,
Alexander Chemeris.

data3.txt
Description: Text document

data3.png
Description: PNG image

latency_reader.c
Description: Text Data

latency_writer.c
Description: Text Data

run_test.sh
Description: Bourne shell script