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 <ktra...@gmail.com> 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: supp...@ettus.com
Web: https://ettus.com/

Reply via email to