Tuesday, 15 January 2013

Steady data transmission over WIFI - Part 4 - Other weirdnesses

So far, 1024 bytes every 20 ms represents a meagre 51KB/s. It's more than enough for transmitting RC commands, but with WIFI 802.11 g it should be possible to peak at about 1MB/s in perfect conditions (which might be incompatible with my need for low latency/steady transmission but anyway...).

Just out of curisosity, I naively tried to increase the amount of data sent per second (x4). Unfortunately it didn't go too well. Here is an example of catastrophic result :)

Weird increase of latency on the reception side
And after few seconds the latency reduces
It's not always broken! Here's a pretty acceptable transmission
Not sure what happens here, but the uglyness seems to happen only in one direction: from the Windows-7 netbook to the Raspberry Pi. Things are relatively normal in the other direction.

Amongst the things that might be worth looking into:
- The MTU
- The way I create the 2-machines WIFI network (I've been using Connectify so far). Maybe I could try an adhoc network
- Nagle's algorithm. It's supposed to be TCP only, but this weird increase/decrease latency phenomenon looks a bit like an algorithm is trying to do something clever.
- Network settings/parameters at the OS level on Windows and Linux
- Or to simplify things a lot: using identical hardware and OS on both sides

I'll investigate that later and try to cover it in another article. If anyone's got advice on the matter, please let me know!

Saturday, 12 January 2013

Steady data transmission over WIFI - Part 3 - Socket buffering

Here is another issue that showed up on the transmission graphs:


On the reception side (the top timeline on the graph), a packet loss seems to translate into a long silence  (longer than just what to be expected from the lost packets) followed by a big burst of data. There's some buffering at play here and I don't want it. It wouldn't help at all with controlling an RC model!

Fortunately there's some control over that: it is possible to set the size of the sending and receiving buffers on a per-socket basis. This is done using the setsockopt function with SO_RCVBUF or SO_SND_BUF as parameters. 

So I went on to expose these buffer sizes as tweakable parameters of my test definition file.
By setting these buffer to the size of the packet I transmit, I expected to achieved a more steady transmission. And indeed, in the same test conditions, it seemed to fix this particular burst problem.