discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Gnuradio Runtime buffers and latency


From: Wheberth Damascena Dias
Subject: Re: [Discuss-gnuradio] Gnuradio Runtime buffers and latency
Date: Thu, 15 Aug 2019 12:21:35 -0300

Thank you for your insight Michael.
My block must always produce a fixed size chunk of data, so it is not directly applicable, but I could use a similar parameter to decide if I would produce stuffing in the current call to work or not.
Then I could query the status of the output buffer to do so.
I will try that.

Thank you
Wheberth


Em qui, 15 de ago de 2019 às 10:29, Michael Dickens <address@hidden> escreveu:
Hi Wheberth - In a similar block I've created in the past, I include a parameter, let's call it "stuffing_size", that is the number of items to stuff when stuffing occurs. If this value is small, then there is "small" latency between when the PDU comes in and its data is output ... but, the block uses a lot of CPU time spinning checking whether it should do "work". If this value is large, then the block uses very little CPU time but the latency between PDU reception and output is "large". You have to play around to find the sweet spot trading off latency and CPU use, but that's not too difficult. Maybe this is the way to go for your situation? Hope this is useful! - MLD

On Wed, Aug 14, 2019, at 10:56 PM, Wheberth Damascena Dias wrote:
Hi all, I have created an OOT block that receives PDUs as input, stores the data in a FIFO buffer and generates a stream as output. Case no data is available at the FIFO, stuffing data is generated. 
The block (kind of) works as intended, but when it is on the system with no data PDUS being received it does its job and generates stuffing. The problem is that, if I understood correctly, the rate of generation is controlled by the blocks downstream (via backpressure) meaning it fills all buffers of the blocks downstream up to the USRP.
This makes the next PDUs that arrive to suffer a very high latency.
I am trying to find a way to limit the buffer of the blocks downstream, but it doesn't feel like the right way to deal with this. Another idea is to query the status of the output buffer (via pc_output_buffers_full()) and generate stuffing data just when it is empty.
Anyone have faced similar issue? Am I in the right direction?
Any comments are appreciated.

Best Regards 
--
Wheberth Damascena Dias
_______________ _____ _____ __ ___ __ _ _ _  _ 

_______________________________________________
Discuss-gnuradio mailing list




reply via email to

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