[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] TCP ack timing
From: |
Mountifield, Tony |
Subject: |
[lwip-devel] TCP ack timing |
Date: |
Fri, 30 Apr 2004 11:15:05 +0100 |
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
***********************************************************************************
- [lwip-devel] TCP ack timing,
Mountifield, Tony <=