discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffer sizes for UDPSink, UDPSource?


From: Michael Dickens
Subject: Re: Buffer sizes for UDPSink, UDPSource?
Date: Mon, 11 Nov 2019 15:27:56 -0500

Hi Jeff - I know of no inherent limitation on UDP I/O sizes, but especially at the small payload sizes you note, regardless of OS. I think the best way forward here is to share your flowgraphs with me (off list) & I'll see if I can replicate the issue (I'm still running Mojave, but again I don't think the OS is making the difference here). - MLD

On Fri, Nov 8, 2019 at 6:19 PM Jeff Kyser <address@hidden> wrote:
Hi,

I’m running gnuradio v3.7.13.5 under macOS Catalina.

We’ve set up transmit and receive flow graphs for a simple BPSK system.

We pass UDP messages which are received by a UDPSource at the start of the Rx flow graph, modulation is performed, and the carrier and symbols are sent to the Tx flow graph via a UDPSink.

The Tx flow graph receives the data in a UDPSource, performs the demodulation, and outputs an assembled message from the bytes.

When I send smaller messages, less than 256 bytes in original length, they pass through both flow graphs just fine, and we receive exactly what we sent.

When I send larger messages, above 256 bytes (actually, they’re about 430 bytes), they don’t make it out of the UDPSource on the front end of the Rx flow graph.

I’ve placed a file sink just before sending the complex data, and one just after receiving.

The actual amount of data going across the UDP Sink —> Source is quite large - a single 180 byte message results in about 700K of complex data.

But the larger messages never get finished.

I’ve set the payload size on the UDPSource and UDPSink to 1024, and there’s been no problem with the smaller messages.

Is there some kind of buffer overrun going on? When we send the 430 byte message, it expands to about 1.4 MB of data, which is all captured on the send side of the interface in the file, but on the receive side, there’s always only about 1.35 MB, which amounts to about 420 characters.

Any ideas on this?

Thank in advance!

-Jeff




--
Michael Dickens
Ettus Research Technical Support
Email: address@hidden
Web: https://ettus.com/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]