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

2019-08-15 Thread Wheberth Damascena Dias
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 <
michael.dick...@ettus.com> 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*
> ___ _ _ __ ___ __ _ _ _  _
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio


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

2019-08-15 Thread Michael Dickens
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*
> ___ _ _ __ ___ __ _ _ _ _ 
> http://www.linkedin.com/in/wheberth
> e-mail:whebe...@gmail.com 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio