Hi Firdavs, I'd fully second what Jeff wrote: Your flow graph is running barely in real-time. So, GNU Radio's optimization for throughput (instead of constant latency) is definitely what you'd want.
Maybe we should take a step back and ask ourselves: *why* is the bursty behaviour a problem for you? Could you elaborate? Best regards, Marcus On Sun, 2018-03-04 at 19:46 -0500, Jeff Long wrote: > I can't think of anything else within the GR core. The scheduler > tries > to maximize sample throughput, but doesn't try to do any kind of > pacing. > > It sounds like whatever is receiving the UDP packets is operating at > its > limits, assuming it would work if the packets were evenly paced. Do > you > know whether the receiver can handle this data rate at all? Or does > it > just have a very small RX buffer? > > You might be able to get the Linux stack to help using tc (traffic > control), depending on the rates you're dealing with. > > On 03/04/2018 07:23 PM, Firdavs Pulat wrote: > > Setting it on the UDP itself didn't change the behavior either. Do > > you > > (or anyone else) have any other ideas? > > > > Thank you > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&u > > tm_campaign=sig-email&utm_content=webmail&utm_term=icon> > > Virus-free. www.avast.com > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&u > > tm_campaign=sig-email&utm_content=webmail&utm_term=link> > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > On Sun, Mar 4, 2018 at 5:16 PM, Jeff Long <willco...@gmail.com > > <mailto:willco...@gmail.com>> wrote: > > > > I think you'd want to set that on the UDP sink itself. > > > > On 03/04/2018 01:30 PM, Firdavs Pulat wrote: > > > > Thanks for the suggestion, Jeff. Unfortunately, that didn't > > seem > > to help. I still see bursty packet transmission. > > > > Btw, currently I have: USRP source --> Low-Pass Filter --> > > ComplexToInterleavedShort --> Endian Swap --> UDP Sink. I > > added > > the set_max_noutput_items line at the output of the Endian > > Swap > > block since that would be the input to UDP. Is that the > > only > > place where I would have to make that change, or on all the > > blocks? > > > > Thanks! > > > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_sourc > > e=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon > > <https://www.avast.com/sig-email?utm_medium=email&utm_sourc > > e=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon>> > > Virus-free. www.avast.com <http://www.avast.com> > > <https://www.avast.com/sig-email?utm_medium=email&utm_sourc > > e=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link > > <https://www.avast.com/sig-email?utm_medium=email&utm_sourc > > e=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link>> > > > > > > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> > > > > > > On Sun, Mar 4, 2018 at 6:44 AM, Jeff Long <willcode4@gmail. > > com > > <mailto:willco...@gmail.com> <mailto:willco...@gmail.com > > <mailto:willco...@gmail.com>>> wrote: > > > > Try yourblock.set_max_noutput_items(1024/itemsize) > > > > > > On 03/03/2018 09:57 PM, Firdavs Pulat wrote: > > > > Hello everyone, > > > > I have a B200mini device I'm communicating over > > USB to a pc > > which is running the gnuradio software. The > > gnuradio > > does some > > processing (e.g., low-pass filtering, data type > > conversion, > > etc), and finally gets to the UDP sink block where > > packets are > > generated and sent through Ethernet to an external > > device. The > > issue I'm having is that, in the UDP block, > > noutput_items*d_itemsize size is alot larger than > > the UDP > > payload size (1024 bytes). So, UDP gets 4-6K worth > > of > > bytes and > > bursts it all out really fast (I can see this > > behavior in > > Wireshark), then waits to buffer up another 4-6K > > bytes, and > > sends it all out really fast. This process then > > continues. Is > > there a way to smooth this out so that it's not > > bursting bunch > > of packets all at once? Otherwise the external > > device > > isn't able > > to keep up and it's leading to tons of dropped > > packets. > > > > I tried setting the max output buffer in python > > but I > > get this > > warning when I run: gr::log :WARN: flat_flowgraph > > - Block > > (endian_swap_impl0) max output buffer set to 2048 > > instead of > > requested 512. > > > > Any ideas on what I can do to change this > > behaviour? > > > > Thanks! > > > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@g > > nu.org>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> > > > > > > _______________________________________________ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@gnu.org> > > <mailto:Discuss-gnuradio@gnu.org <mailto:Discuss-gnuradio@g > > nu.org>> > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio> > > <https://lists.gnu.org/mailman/listinfo/discuss-gnurad > > io > > <https://lists.gnu.org/mailman/listinfo/discuss-gnuradio>> > > > > > > > > _______________________________________________ > 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