# How to control latency

**URL:** <https://www.ruby-forum.com/t/how-to-control-latency/241351>\
**Category:** GNU Radio\
**Created:** [March 31, 2015, 8:21pm UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351 "2015-03-31T20:21:37Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [March 31, 2015, 8:21pm UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351/1 "2015-03-31T20:21:37Z")

</div>

Hello,

I have a system where I acquire a signal through an Ettus N210 at 200  
kHz and I process it through a few GNURadio blocks. Those blocks include  
a first low pass filtering and decimation to 1 kHz sampling rate and  
further resampling down to 10 Hz or so.

In this configuration the output samples are delivered to the last block  
of the flow-graph bunched in packets so that a packet is received every  
3 seconds.

This does not seem to depend on the last resampling neither on the  
maximum buffer site (set calling `tb.run(size)` where `tb` is the top  
block of the flow-graph). I also tried to change the UHD frame size with  
the `recv_frame_size`, but it had no effect on the latency.

As I’m trying to implement a control loop, I would like to obtain data  
at a real 10 Hz rate from my last block. I think the system should be  
able to handle the computing overhead just fine.

How can I accomplish this?

Thank you. Cheers,  
Daniele

---

<div class="post-metadata">

**Author:** ![Daniele\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/74df32/32.png) [@Daniele\_N](https://www.ruby-forum.com/u/Daniele_N)\
**Post date:** [April 1, 2015, 12:32am UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351/2 "2015-04-01T00:32:44Z")

</div>

Daniele,

GNU Radio tries to maximize the size of the chunks of data it deals  
with.  
Clearly that works well for high rate data, but not low rate data.  
There  
are some handles to control buffer sizes and things within GNU Radio,  
but  
you may have better luck just using a much higher sample rate. If you  
just  
decimate less, and have a sample rate of about 10 kHz you won’t have  
this  
problem. You’ll use more CPU, but it will still be a tiny amount.

Matt

On Tue, Mar 31, 2015 at 11:20 AM, Daniele N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![Daniele\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/74df32/32.png) [@Daniele\_N](https://www.ruby-forum.com/u/Daniele_N)\
**Post date:** [May 13, 2015, 5:48pm UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351/3 "2015-05-13T17:48:32Z")

</div>

On 01/04/15 00:30, Matt E. wrote:

> Daniele,
> 
> GNU Radio tries to maximize the size of the chunks of data it deals  
> with. Clearly that works well for high rate data, but not low rate  
> data. There are some handles to control buffer sizes and things within  
> GNU Radio, but you may have better luck just using a much higher sample  
> rate. If you just decimate less, and have a sample rate of about 10 kHz  
> you won’t have this problem. You’ll use more CPU, but it will still be  
> a tiny amount.

Hello Matt,

thank for your answer. Sorry if I come back to this so late.

The low samples rate are unfortunately necessary in my application, or I  
don’t know how to avoid them. What I’m implementing is a control loop  
and the communication with the actuator is rather slow (commands send  
through a RS232 connection).

However, I found where the problem was coming from: I was using gnuradio  
fft filter implementation, and it looks like that this block has a  
minimum number of output elements that increases rapidly with increasing  
number of taps. I suspect this is due to alignment requirements of the  
underlying fftw library, but I haven’t check that. Indeed, using higher  
hardware sampling rates required longer filters and made things worst.

Switching from fft filter to simple fir filter blocks, the problem of  
too large buffers goes away and at those modest sampling rates the  
higher computational cost is not a problem.

Cheers,  
Daniele

---

<div class="post-metadata">

**Author:** ![Daniele\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/74df32/32.png) [@Daniele\_N](https://www.ruby-forum.com/u/Daniele_N)\
**Post date:** [May 13, 2015, 6:46pm UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351/4 "2015-05-13T18:46:23Z")

</div>

Hi Daniele,

alignment requirements for the FFTw aren’t that strict, but you’ll have  
to wait for a decimation\*ntaps of samples to accumulate before you can  
do the FFT.

Greetings,  
Marcus

---

<div class="post-metadata">

**Author:** ![Daniele\_N](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/74df32/32.png) [@Daniele\_N](https://www.ruby-forum.com/u/Daniele_N)\
**Post date:** [May 13, 2015, 8:52pm UTC](https://www.ruby-forum.com/t/how-to-control-latency/241351/5 "2015-05-13T20:52:34Z")

</div>

Hello Marcus,

I went looking at the code and I found this:

d\_fftsize = (int) (2 \* pow(2.0, ceil(log(double(ntaps)) / log(2.0))));  
d\_nsamples = d\_fftsize - d\_ntaps + 1;  
set\_output\_multiple(d\_nsamples);

which I’m not sure I understand, but is in agreement with what I  
observe. Can someone explain the reason of the subtraction in line two  
of the above code snippet?

Thanks. Cheers,  
Daniele