32

Would sending lots a small packets by UDP take more resources (cpu, compression by zlib, etc...). I read here that sending one big packet of ~65kBYTEs by UDP would probably fail so I'm thought that sending lots of smaller packets would succeed more often, but then comes the computational overhead of using more processing power (or at least thats what I'm assuming). The question is basically this; what is the best scenario for sending the maximum successful packets and keeping computation down to a minimum? Is there a specific size that works most of the time? I'm using Erlang for a server and Enet for the client (written in c++). Using Zlib compression also and I send the same packets to every client (broadcasting is the term I guess).

Community
  • 1
  • 1
pandoragami
  • 5,387
  • 15
  • 68
  • 116

4 Answers4

34

The maximum size of UDP payload that, most of the time, will not cause ip fragmentation is 

MTU size of the host handling the PDU (most of the case it will be 1500) -
size of the IP header (20 bytes) -
size of UDP header (8 bytes)

1500 MTU - 20 IP hdr - 8 UDP hdr  = 1472 bytes

@EJP talked about 534 bytes but I would fix it to 508. This is the number of bytes that FOR SURE will not cause fragmentation, because the minimum MTU size that an host can set is 576 and IP header max size can be 60 bytes (508 = 576 MTU - 60 IP - 8 UDP)

By the way i'd try to go with 1472 bytes because 1500 is a standard-enough value.

Use 1492 instead of 1500 for calculation if you're passing through a PPPoE connection.

Davide Berra
  • 6,387
  • 2
  • 29
  • 50
13

Would sending lots a small packets by UDP take more resources ?

Yes, it would, definitely! I just did an experiment with a streaming app. The app sends 2000 frames of data each second, precisely timed. The data payload for each frame is 24 bytes. I used UDP with sendto() to send this data to a listener app on another node.

What I found was interesting. This level of activity took my sending CPU to its knees! I went from having about 64% free CPU time, to having about 5%! That was disastrous for my application, so I had to fix that. I decided to experiment with variations.

First, I simply commented out the sendto() call, to see what the packet assembly overhead looked like. About a 1% hit on CPU time. Not bad. OK... must be the sendto() call!

Then, I did a quick fakeout test... I called the sendto() API only once in every 10 iterations, but I padded the data record to 10 times its previous length, to simulate the effect of assembling a collection of smaller records into a larger one, sent less often. The results were quite satisfactory: 7% CPU hit, as compared to 59% previously. It would seem that, at least on my *NIX-like system, the operation of sending a packet is costly just in the overhead of making the call.

Just in case anyone doubts whether the test was working properly, I verified all the results with Wireshark observation of the actual UDP transmissions to confirm all was working as it should.

Conclusion: it uses MUCH less CPU time to send larger packets less often, then the same amount of data in the form of smaller packets sent more frequently. Admittedly, I do not know what happens if UDP starts fragging your overly-large UDP datagram... I mean, I don't know how much CPU overhead this adds. I will try to find out (I'd like to know myself) and update this answer.

JoGusto
  • 923
  • 8
  • 8
  • 1
    I've read that using sento instead of using a connected udp socket can produce some overhead because the kernel temporarily connects the socket during sendto. If you are in a unicast scenario this should not be a problem at all. Didn't tested it by myself though but would be interesting to test your scenario with a connected udp socket. Source: https://stackoverflow.com/a/638306/2298490 – grill2010 Jul 13 '18 at 16:23
5

534 bytes. That is required to be transmitted without fragmentation. It can still be lost altogether of course. The overheads due to retransmission of lost packets and the network overheads themselves are several orders of magnitude more significant than any CPU cost.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I wonder what the direct effect on packet of fragmentation is. In my application, when I go from 508 to 509, it seems that a '\0' is appended at the end of the 2nd packet. I wonder whether it depenmds on my particular implementation or it is a trule? –  Oct 29 '13 at 06:58
  • 1
    @mavErick The trailing null comes from, or is incorrectly observed by, your code. UDP doesn't do that. – user207421 Dec 16 '13 at 11:29
-20

You're probably using the wrong protocol. UDP is almost always a poor choice for data you care about transmitting. You wind up layering sequencing, retry, and integrity logic atop it, and then you have TCP.

Ross Patterson
  • 9,527
  • 33
  • 48
  • 4
    "retry"? But I thought that was what tcp about...resending packets to get the job done. I'm doing this for an online game so tcp will most likely be too slow, or thats what everyone else says. – pandoragami Feb 21 '13 at 12:58
  • 1
    "Everyone" is often wrong. If you're concerned that data might not arrive, you need TCP. – Ross Patterson Feb 21 '13 at 15:59
  • Ok then what would be the most efficient tcp packet size considering Nagel, etc.. – pandoragami Feb 21 '13 at 23:03
  • 1
    For TCP, you don't choose the packet size. You just write bytes into one end of the socket and they come out the other. – Ross Patterson Feb 22 '13 at 00:13
  • 19
    If on the other hand you don't care whether or not the packets arrive or what order they arrive in (i.e. most streaming data protocols) then UDP is the perfect choice. – Markus Koivisto Dec 12 '13 at 14:47
  • 5
    I used UDP for a view finder in my camera app. UDP is perfect in this case. TCP is unnecessary and slow. How many times you use TCP directly in a real life project? Not many either. HTTP is probably mostly used. – jack Jan 19 '15 at 00:26
  • @jack I've used TCP repeatedly, especially before the net became all-HTTP-all-the-time. And yes, for video where you don't mind a glitch between frames and you're more concerned about frame delay than stream continuity, UDP is perfect. – Ross Patterson May 12 '15 at 01:46
  • StackOverflow is not a place for editorializing and pontificating. If someone is asking about UDP you should respect they know the difference from TCP and chose UDP for a reason. Thanks. – androticus Jun 26 '23 at 00:12