What is the maximum buffer size for UDP transmission?

[gfhdfghdfghdfg]

As far as I understand, the maximum size of packet for UDP transmission should be 8192 bytes. For some reason, when I try to receive packets larger than 544 bytes, I get error 113 (Possible reason(s): LabVIEW: A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram was smaller than the datagram itself.).
I even tried to explicitly set the Tx and Rx buffers to 8192 bytes as was done here
http://digital.ni.com/public.nsf/allkb/D5AC7E8AE545322D8625730100604F2D?OpenDocument
but that didn't help. What can be the reason for that?
I attached the code which is a slightly modified LV Example code (the only changes being addition of the vi for buffer size setting and changing the data to be sent/received from scalar to an array of variable size). The largest packet I can send/receive without error is 68 DBL values (544 bytes).

[Kevin_Price]

I hoped someone else was gonna answer this b/c I don't know if my comments will be all that relevant.

I'm not any kind of expert about UDP, but last year I needed to put together a UDP client-server architecture.   Between asking around, doing other research, and tinkering, I was able to setup a very large receive buffer (5 megabytes) on the client side using the same utility you linked to.  On the server side, I was sending datagrams of up to 64000 bytes.  It runs fine serving up a minimum of 4 channels of AI waveforms at 50 kHz sample rate which amounts to about 1.6 MBytes/sec.

I don't know exactly how the following affect the allowable datagram size or receive buffer size, but this is what I worked with:

- used local UDP multicasting -- 1 writer with time-to-live==0, multiple readers

- single local PC, multiple independent executables referencing same NIC for all UDP communication

- Windows 10

A quick internet search about datagram sizes found, well, a lot of things.  Overall, it seems that if you're going out over the internet at large it isn't surprising that you're limited to a datagram size of ~544 bytes.  If you're in a more local networking environment, there may be a way to use much larger datagrams.

-Kevin P

[gfhdfghdfghdfg]

Kevin, thanks for your reply.

I am basically using the "Simple UDP" example from the examples supplied with LV. It simply transmits data from one port to another of the local machine, so no internet is involved.

In the help to UDP Write function it is said that "In an Ethernet environment, restrict data to 8192 bytes. In a LocalTalk environment, restrict data to 1458 bytes to maintain gateway performance." So I am not sure how you could use so large buffers.

Also, here https://forums.ni.com/t5/LabVIEW/UDP-receive-buffer-default-size/m-p/1795610#M620061 there is a way to control the buffer with a registry key, but it seems to be only valid for Windows XP since this key is absent in Win 7.

[Kevin_Price]

I'm treading on thin ice w.r.t. what I truly understand about UDP, multicasting, and networking in general.  I too am going port to port on a local machine, no switch, no router, no gateway out to a wider network.  I never did any messing around with registry settings.  The main thing on the sending side was to set time-to-live at 0 b/c the messages don't need to pass through any external network hardware.

But what I described *has* been working fine, with datagrams as large as 64000 bytes.  (Actually, very slightly larger.  I'm sending arrays of AI waveforms containing up to 8000 samples aggregate at 8 bytes each.  Plus some additional bytes that go along with the waveform as t0, dt, and DAQmx attributes.)

It's possible that different rules apply for multicasting?  Try the "UDP Multicast" shipping example and see if that might work for you.  Set "time-to-live" at 0 to keep messages confined to your local machine, preventing them from going out onto the wider network.

-Kevin P

[Ben]

It has been a long time since was down in the weeds...

Kevin,

Did I understand you correctly that you were running on a single machine and never hit to physical wire?

How you got away with that is hidden deep in the UDP stack of the OS you were running on. It MAY habe been smart enough to see the comm. was on the same machine to Ethernet and its limitations never entered the picture.

But to got out the physical wire the packet has to fit into the Ethernet packet size limitations. They were put in place because when it was first invented Ethernet was section of Coax that was shared and to prevent one machine from swamping the network the packet size was limited to allow for CDMA to be effective.

Not that anything I said applies and actually helps.

Ben

[Kevin_Price]

Yep, you heard right.  Several independent executables on a single Win 10 box communicate via the same physical network card.  No physical wire.

I had a couple followup conversations since yesterday with colleagues who are better versed in networking stuff.  The long and short of what I gathered is that:

- I was reaping an advantage by sticking on one local network card

- trying to push this through a switch to another PC would definitely be a problem

- a direct connection to another PC via crossover cable would be iffy at best

Thus, when it moves out of beta into a version release this fall, I'll be converting over to (probably) network streams.  I may need to support an overall bandwidth a bit over 3MB/sec and at least *want* to support the possibility of server and clients running on separate computers.

-Kevin P

[rolfk]

---

@Kevin_Price wrote:

Yep, you heard right.  Several independent executables on a single Win 10 box communicate via the same physical network card.  No physical wire.

I had a couple followup conversations since yesterday with colleagues who are better versed in networking stuff.  The long and short of what I gathered is that:

- I was reaping an advantage by sticking on one local network card

- trying to push this through a switch to another PC would definitely be a problem

- a direct connection to another PC via crossover cable would be iffy at best

Thus, when it moves out of beta into a version release this fall, I'll be converting over to (probably) network streams.  I may need to support an overall bandwidth a bit over 3MB/sec and at least *want* to support the possibility of server and clients running on separate computers.

---

WinSock and all other network socket implementations I know of do have a short circuit mechanism for localhost traffic. By default that data never even touches the network adapter chip but is directly routed through a shared memory pool between the two processes from inside the socket layer implementation.

That is why you can fairly easily reach speeds for localhost traffic that actually exceeds the speed of the physical network interface in your computer (more of a theoretical thing nowadays with Giga Ethernet and beyond but still). the memory bandwidth in your computer (and the process CPU saturation of course) are the only factors that will really limit such localhost traffic throughput..

[alexderjuengere]

@rolfk wrote:

That is why you can fairly easily reach speeds for localhost traffic that actually exceeds the speed of the physical network interface in your computer (more of a theoretical thing nowadays with Giga Ethernet and beyond but still). the memory bandwidth in your computer (and the process CPU saturation of course) are the only factors that will really limit such localhost traffic throughput..

---

yes!

I have done several Roundtrip-Test sending Data  via UDP from one Windows 10 PC to another PC via a 1 GBit/s or 125 Mbyte/s Ethernet-cable connection.

When using localhost on the same PC  to debug, you can easily reach more than 125 Mbyte/s - but for the real Roundtriptest with 2 PCs involved, I hit a limit around 122-123 Mbyte/s.

Above this empirically found limit, you inevitably get errors from the UDP send or receive .vis, and/or  you start to receive less bytes than sent before.

---

@gfhdfghdfghdfg wrote:

I even tried to explicitly set the Tx and Rx buffers to 8192 bytes

---

I had to modify the number of rss Queues (which is limited by the amount of cpu cores), and Interruption Moderation Rate (set to extreme) to "stabilze" my test results.