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 Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
