TCP Latency

[jfperusse]

Hi,

 

I'm currently working on a DS multiplayer action game (only 2 players for now). This is a port from a PC game that uses TCP for the networking.

 

In that game, I send the stylus position and buttons to the other player every "n" frames (where n is a compile time constant and I use a modulo to update/send the controls only every n frames).

 

The PC game used to run fine at 30 FPS while sending the inputs every frame (on a LAN with 4 players), so what I'm trying to do on DS is to send the inputs at least every 2 or 4 frames (after more than 6 frames we start to notice the "lag" with the inputs.)

 

However, I seem to be having latency problems... With ~6 frames of delay (~100ms), after a few seconds, I start receiving the inputs lately (network lag waiting for recv). I created a simple PC v.s. DS program to calculate the round trip time on the PC. The program is very simple. The PC connects to the DS and when you press a key, it sends a short message to the DS and wait for an answer. That way, I calculated a round trip around 50-60ms, which is really high... PC to PC, it was never going higher than 20ms...

 

I tried changing the timer3 frequency (the timer used to call Wifi_Timer(ms) and update the wifi). If I use a higher frequency without changing the Wifi_Timer parameter (ms since last call), I seem to have a better round trip time, but I really don't know what should be change in my case to have the best results...

 

Any idea?

 

(By the way, I'm using PAlib, so I changed the timer3 period defined in PAlib (50ms).)

 

Thanks for your help!

 

JF

 

P.S. I'm using blocking sockets. In order not to block on recv() calls, I use select().

Edited September 15, 2006 by jfperusse

[masscat]

If the amount of data being sent is not large then it may not be sent out immediately and buffered instead. This is done to try to reduce the number of TCP packets sent reducing the cost of the TCP packet overhead.

Normally you can set a socket option to cause data to be sent out immediately (TCP_NODELAY) but this functionality is not in dswifi yet.

 

To get the same behaviour you can hack the dswifi source. In the function sgIP_TCP_Send there is the following comparison.

if( j>SGIP_TCP_TRANSMIT_IMMTHRESH && rec->tcpstate==SGIP_TCP_STATE_ESTABLISHED)

SGIP_TCP_TRANSMIT_IMMTHRESH is set to 40; unless there are more than 40 bytes waiting to be sent the packet will not get sent until the timer function fires. By setting SGIP_TCP_TRANSMIT_IMMTHRESH to 0 a call to send() will cause a packet to get sent out straight away.