[lwip-devel] TCP ack timing

[Mountifield, Tony]

Hi All,

I am doing some testing of TCP streams, and have noticed some strange timing 
behaviour. I would be grateful for any comments or suggestions.

Unit A (a Linux machine) is sending a continuous stream of data to unit B 
(embedded device running LWIP). I wasn't satisfied with the transfer rate and 
the fact that there were frequent brief pauses (several tenths of a second), so 
I watched the transfer with tcpdump.

What I saw was the window size advertised by B going to zero after receiving a 
packet, and then a short while later (say .2 or .3 seconds) readvertising a 
window of 2048. Sometimes this readvertisement would appear quicker, say 50ms, 
but sometimes unit A had to send a data-less packet (window probe?) to elicit a 
new window from B.

The application in B is consuming the data as quickly as it can, and is using 
the sockets API.

It seemed to me that when the app on B consumed the incoming data, the 
re-opened window wasn't being advertised straight away, so I modified the app 
to write a small amount of data via the socket back to A, each time it received 
incoming data. The theory was to see if the ack/win in the outgoing data would 
give an earlier notification to A. This was in fact what happened. The data 
rate of the main flow from A to B more than doubled.

Is this correct and/or expected behaviour? Or is there a tweak required to 
efficiently support continuous unidirectional data flows?
My knowledge of the deeper esoterica of TCP algorithms is fairly limited.

Cheers
Tony
-- 
Tony Mountifield
Contractor @ Tandberg TV
Strategic Park, ext 3390
Tel: 023 8057 3390


***********************************************************************************
This email, its content and any attachments is PRIVATE AND
CONFIDENTIAL to TANDBERG Television. If received in error please
notify the sender and destroy the original message and attachments.

www.tandbergtv.com
***********************************************************************************