Jump to content

Packet loss


Recommended Posts



over at forum.gbadev.com, some people are discussing Wifi as possible carrier for MIDI data. The results so far are as follows: A TCP connection has barely enough performance to be usable; UDP would be great but suffers badly from packet loss, even if on the same LAN. (As an example, ping yields about 11% packet loss, which kills music applications.)


The question is now: Is this a fact of life for the DS, or is it possible to improve that number by DSWifi tweaks? Anyone know?


Thanks a lot in advance,


Link to comment
Share on other sites

A custom retransmitting UDP protocol should be sufficient for this sort of thing, and TCP will do a pretty good job too - for local connections you should be able to get a minimum of 2 to 3 times the performance necessary, even with a lossy connection. That being said, 11% packet loss isn't typical in my experience, and if it does occur, it's likely an issue with signal strength and distance between the DS and router/AP

(actual wifi speed is approximately 2mbit, I've achieved transfer rates through tcp of roughly 80kbyte/sec - and this will improve with future libraries)



Link to comment
Share on other sites

OK, so it's probably my connection that's at fault; I'll investigate that.


As far as the performance is concerned: Yes, the bandwidth of the 2Mbps link is more than enough to accomodate MIDI data. Unfortunately for MIDI, latency is just as important as bandwidth, if not more. A rule of thumb is that you will notice if there is more than a ~30ms delay between your keyboard and the sound generator. Even if just one in a hundred notes comes significantly later, it will break the flow of playing. On a lossy connection (mine here, specifically), I've seen lag times of up to a second fairly often. That was the reason for my question.

Link to comment
Share on other sites

If you're worried about latency, you should certainly use a custom realtime UDP protocol - you can be guaranteed latency under 30ms for small messages unless more than x number of retries have to be made (depending on the size of the packet, and other factors) Data is sent at 2mbit, which is 2 million bits per second exactly; If you'd like exact timing information, see the following data:


2mbit is exactly 2 million bits per second, or half a microsecond per bit.

The following elements are present in a UDP packet:

(802.11 phy overhead:)

96 bits plcp preamble

32 bits plcp header

(total of 128 bits / 16 bytes)

(802.11 protocol overhead:)

24 bytes 802.11 header

4 bytes extra (for WEP IV)

(now, actual data:)

8 bytes LLC header

20 bytes IP header

8 bytes UDP header

x bytes data (your data goes here)

4 bytes 802.11 CRC32


Soooo, adding all that together gets us:

84+x bytes (where x is the number of bytes in your packet)

which is

672+8x bits (or 336 + 4x microseconds)

as you can see, 802.11 is more than capable of delivering a message within 30ms, but the question is more one of whether the message gets received :banghead:


TCP is presently set up for reliable operation over long distances, so it's really not ideal for this sort of application; though this is one area I plan to improve in the future.


Anyway, good luck :D



Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...