Re: UDP Rate
Re: UDP Rate
- Subject: Re: UDP Rate
- From: "Matt Slot" <email@hidden>
- Date: Sat, 21 Feb 2004 23:38:57 -0500
Sat, 21 Feb 2004 00:48:40 -0700
>
Hi, I have written a reliable UDP protocol for our games that uses
>
windowing, resending, ignoring duplicate packets, etc. It's easily the most
>
hellish thing I've ever written, I highly recommend against anybody doing
>
it, it was harder than opengl, sound double buffering, anything :) Anyway,
>
it all works, but I am getting some weird numbers for the throughput. Here
>
they are, at a 90% packet success rate:
As a sanity check, 10% packet loss is rather high unless you are furiously
blasting packets across the wire, or communicating with someone on the far
side of an ocean. That said, it's important to be able to cope with errors
and packet loss, so it's good that you are testing that way.
>
Does anyone know why airport is so slow? Are the packets just
>
inherently unreliable over radio? Airport should be getting more like
>
1MB/sec.
100Mbit Ethernet is faster than 11Mbit, and can operate in full duplex.
Remember that each host on Airport must compete for the same bandwidth.
>
Also, is there some setting, like only let 10% of a LAN's traffic be UDP
>
packets? These numbers all seem very low to me, certainly lower than the
>
theoretical ~10MB/sec for ethernet and who knows how high for localhost.
The low level stack, routers, and remote host may all limit the throughput
rate -- especially if you are just blasting data as fast as you can go. An
Ethernet frame or UDP packet may be dropped if there isn't enough room in
the buffer.
>
I also noticed that the program is extremely sensitive to things like
>
GetNextEvent() and printing to the console. If I do that very much at all,
>
the profiler shows an obscene amount going to the GUI. For instance,
>
running the program localhost only runs half as fast as running on LAN
>
because it draws twice as many lines to the screen, even though I am only
>
writing a line every 100k! (send+receive, see?)
I've definitely seen this when using Metrowerks and SIOUX. Under OS9, I'd
highly recommend something like DCon for serious logging.
>
I am going to use 512 byte packets with a window size of 16 packets, with a
>
min window send interval of 10ms (normally averages 100ms tho). So that is
>
512x16x100 = 819200 bytes/sec. I never see anywhere near this, I can only
>
get to 350 k/sec with 512 byte packets.
Remember 28 bytes of UDP and Ethernet header. That's an extra 5% for each
packet at 512 bytes.
>
1. Is the sockets stack 64k? I can only seem to send about 500k/sec (512
>
bytes times 128 length window = 64k) about 8x a sec and get no loss rate.
>
Same for 8192x8=64k at about 16x a sec. Is this why localhost is slower
>
than network, I am running out of memory? Or is there something inherently
>
slow with calling sendto() and recvmsg()?
An earlier response indicated the default sizes of various buffers. When
sending to localhost, you have just the send side and recv side buffers.
When sending over the wire, you have more buffers on each Ethernet card,
hubs, and (technically) even the wire itself acting as a buffer.
>
2. Is the udp mtu in OS X 8192 bytes? I can't seem to send 16384 byte
>
packets, or even 16000 bytes. And I thought the mtu for ethernet was 64k.
For Ethernet, your MTU is 1500. For Airport, it's 1492. You can write
packets larger than that, but they will be fragmented and reassembled
over the wire -- causing more latency and packet loss.
Probably 500 or 1000 bytes is a good working limit, but remember that
real world data is generally smaller unless you are doing something
bandwidth intensive (downloading levels).
>
3. If the packet send success goes over 90% I turn up the speed, if it
>
goes below 75%, I turn it down. Are these reasonable numbers? I am
>
afraid maybe modems never go above 80% for instance.
In my experience, 10% packet loss indicates a serious network problem.
Excess traffic, crimped Ethernet cable, flaky router, noisy wireless, or
random solar flare can certainly cause erratic spikes of packet loss, but
these are the exception and not the rule.
Perform your own tests, but here's my experience:
100MBit Ethernet LAN - 99.9% success
US only Cable or DSL - 98% success
Analog Modems - 95% success (very sensitive to flooding tho)
Transatlantic - varies: 97% on a good link, 85% on a bad one
>
4. Is there any benefit to threaded sockets? I am going to be calling
>
Idle() at least 30 fps in my game's loop, so I can't see how it would go
>
faster.
A 30fps network heartbeat on each host means that you may wait up to 33ms
before receiving and responding to an incoming packet. That said, if your
physics engine is single threaded, there isn't an advantage to receiving
updates faster than it can handle them. About all your network layer could
do is ack or resend any outstanding packets (which isn't all bad).
>
5. Are my numbers even close to right? Have any of you programmed a UDP
>
game before? Is UDP just for signalling or something? My bandwidth should
>
be 10 times higher than it is, and I don't know if my main loop just isn't
>
running fast enough, or if the OS/network is limiting me. Okay I have
>
infinite questions so I will stop now.
Well, I understand that you are stress testing your system to make sure
it's solid -- but yes, your numbers seem a bit skewed. Ignoring NAT, UDP
is a reasonable choice for games. You avoid some of the limitations of
TCP (flow control, Nagle's algorithm, in-order sends) but you lose the
fine control over bandwidth that these features provide.
To strike a balance, some network libraries (notably OpenPlay) open both
a TCP and a UDP endpoint for each host. This way, the developer can use
TCP for the bandwidth intensive or reliable data (levels, chat), and UDP
for timely but unreliable status updates (location).
Anyway, to answer your question, a host in a network game should only be
sending about 6-10 packets per second, a server proportionally more. In
addition, packet size should be minized where ever possible. Never send
a packet larger than the MTU.
Good luck,
Matt
+--------------------------+-----------------------------------+
| Matt Slot | Ambrosia Software, Inc. |
| Bitwise Operator |
http://www.AmbrosiaSW.com/ |
+--------------------------+-----------------------------------+
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.
| References: | |
| | >UDP Rate (From: Zack Morris <email@hidden>) |