|
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.
data.txt
Description: Text document
latency_reader.c
Description: Text Data
latency_writer.c
Description: Text Data
run_test.sh
Description: Bourne shell script
data.png
Description: PNG image
data2.png
Description: PNG image
data2.txt
Description: Text document
[Prev in Thread] | Current Thread | [Next in Thread] |