Hi,
I’m currently working on a network game using UDP, and I’m curious whats better, to send many small packets or to send fewer but larger packets in terms of packet loss and overall performance? Any thoughts?
Hi,
I’m currently working on a network game using UDP, and I’m curious whats better, to send many small packets or to send fewer but larger packets in terms of packet loss and overall performance? Any thoughts?
Carmack for Quake 3 claims that bigger packets with redundant data in are a better bet.
Kev
All hail King Carmack!
Really this depends on your game needs.
If you need in-order reliability then its hard to beat TCP for a basic protocol because the network cards and rpouters “understand” it and are doing thinsg to try to speed thinsg up (and yes, I just checked that recently with a network expert.)
If re-transmit times worry you and you have the bandwidth, then you can always do a UDP side-band of a window of packets to fill in with when stalls occurr (assumign the UDP arrives.) We did this at TEN and it did a pretty good job of taming latency spikes in Quake2.
The problem with JC is that he sometimes confuses himself with otehrs he shares initials with
Or to put it another way, he knwos a hell of alot within his area, but he doesnt always know what he doesnt know. Remember that he told the gaming world that he had the latency problem licked with his Quake2 solution…
Well, I will disregard out of order packets, but I’ve read somewhere that big packets are lost more often than small packets, but I dont know if there’s any truth in that.
The other Q3 guy (don’t remember name) had a GDC talk when he mention this things. They sent the game list in one huge udp packet and it would get consistently lost. This was probably packets that was larger than 10k.
I think 1500 bytes i a magic limit for some reason but don’t remember why. 512 bytes might be another limit. Might have something to do with router priorites and packet splitting.
Please correct me if I’m wrong.
edit: Ethernet payload is max 1500 bytes
Ok, so perhaps I should ask what you guys think how big a big packet is? I’m looking to send about 30 packets/s if they are big (250 bytes) or many more, perhaps 80 packets/s if they are small (100 bytes). The network topology is LAN or broadband internet.
I’d go with the 250 bytes packets, but even 30/s is a bit much over the internet.
MTU is magic. Basically over MTU it gest broken into multipel packets. if you lose any one of them you cant reconstruct the packet soits all lost.
I gather this is the issue your addressing.
Yep as stated above MTU (Max transmission unit). This is 1500 bytes for CABLE modems. If you have modem users your UDP packages shouldent exceed 500 bytes. Having your UDP cut up means that you have to handle it, by adding a sequence number to your UDP packages. Then you can reassemble your data at the appliacation layer. Unfortunatly you could risk loosing a package say 2 of 3 and everything is lost (unless you implement a rerequest at application layer)
so stay below 500 bytes
[quote=“Middy,post:10,topic:25047”]
Just to be clear. UDP packets can be fragmented when transmitted. But you do NOT have to handle it yourself. The packet will always be recieved exactly as it is sent. However, large packets that get broken up may take longer to send and is more likely to get lost. So staying inside the magic boundries may improve performance.