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 <mailto:e-mail%3awhebe...@gmail.com>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Discuss-gnuradio mailing list

Reply via email to