unstable tcp receive times

I'm writting a client using socket to receive EEG data from a recording PC (RP) to produce some online feedback.

The RP has a server which sends the data over TCP. The data is being sent with blocks, each having a header and data (alltogether is 2560 bytes). The blocks are sent every 20 ms (50 Hz).

When I run the client, it receives the blocks in bursts (e.g. one block for 40ms then next one instantaniously, 0ms). First I thought this is because the server uses Nagle's algorithm and packets are small to be sent individually, but when I reduce the block size to, say, 400 bytes, the recv() returning time becomes much more stable (around 20ms now. Still some variation but no bursts anymore). Even with the 2.5k packets, the total required bandwidth doesn't look large: 50*2560 = 128 kB/s. Same unstability is present when I'm running both client and server on localhost. What might be the problem here?

Herer's the (simplified) client's code:

# ...
# packet definitions as ctypes structures:
from protocol_defines import header, message
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((addr, port))
hdr = header() # 24 bytes
msg = message() # 2560 bytes
while True:
 s.recv_into(hdr) # this thing should return once the hdr buffer is filled
 # ... check if the message is ok ...
 s.recv_into(msg) # this thing should return once the hdr buffer is filled
 print time.time() # this is how I measure arrival times

UPD: I checked the conversation with wireshark. The problem seems to be in the client: it sends [ACK] packets only after 40ms since the last server's [PSH, ACK] (the server responds almost instantaneously on client's [ACK]). The server has already acquired 2 packets by the time, so it sends 2 glued packets. The question remains opened :(

PS: I'm using Ubuntu with 2.6.35 kernel

• 1
  I'm not very good at network programming, but I believe the problem is somewhere in server (and related to network buffers). Have you tried to run a network sniffer (I can recommend wireshark) to check what's going on on network level.

  rvs

  – rvs

  2011年12月23日 16:00:00 +00:00

  Commented Dec 23, 2011 at 16:00
• Could be, but I've tried two different server implementations both localy and remotely and had the same pattern. Actually that's a nice idea to wireshark the thing, I'll try it.

  dmytro

  – dmytro

  2011年12月23日 16:07:30 +00:00

  Commented Dec 23, 2011 at 16:07
• looks like it's a client's problem. Check the UPD

  dmytro

  – dmytro

  2011年12月24日 18:25:34 +00:00

  Commented Dec 24, 2011 at 18:25
• 1
  The Client is allowed to Delay its ACK as per the TCP spec, it can do so because it can save bandwidth and TCP overhead if it can piggyback it on some data to transmit, so it can wait to see if you give it some data to send. srohit.tripod.com/tcpslowstart.txt. However, after the "Slow Start" of the TCP connection, the server should not wait for every ACK before sending the next packet: srohit.tripod.com/tcpslowstart.txt

  bdk

  – bdk

  2011年12月24日 18:41:19 +00:00

  Commented Dec 24, 2011 at 18:41

2 Answers 2

Start asking to get answers

Find the answer to your question by asking.

Explore related questions

See similar questions with these tags.