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

Em qui, 15 de ago de 2019 às 10:29, Michael Dickens <> 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
Discuss-gnuradio mailing list

Reply via email to