[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] UDP Sink sending bursty packets
From: |
CEL |
Subject: |
Re: [Discuss-gnuradio] UDP Sink sending bursty packets |
Date: |
Mon, 5 Mar 2018 12:26:03 +0000 |
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 <address@hidden
> > <mailto:address@hidden>> 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 <address@hidden
> > com
> > <mailto:address@hidden> <mailto:address@hidden
> > <mailto:address@hidden>>> 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
> > address@hidden <mailto:address@hidden>
> > <mailto:address@hidden <mailto:address@hidden
> > 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
> > address@hidden <mailto:address@hidden>
> > <mailto:address@hidden <mailto:address@hidden
> > 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio