The TCP stack in
10.0.0.13 is broken.
It performs Delayed ACK on PSH segments.
This is why you have these 150ms delays before an ACK is generated.
A host SHOULD do delayed ack if the total amount of received unacked data is less than two full sized segments (2*MSS).
However, delayed ack should not be used for segments that has the PSH bit set.
PSH segments are always ACKed immediately.
You MIGHT be able to workaround this breakage by disabling Nagle on
10.0.0.13 but this often means you also get a small
degradation of performance.
There is a reason for Nagle to be used and the only time you should
ever disable it is for cases like this : Broken TCP stack or broken
application.
I would advice to see with the vendor for the OS of
10.0.0.13 if they
have a patch that fixes this bug in the stack instead of changing the
Nagle settings.
On 2/8/06, Arnaud Lesauvage <thewild@xxxxxxxxxxx> wrote:
Hi list !
Sorry if this is not the right place to post this kind of request.
I have a problem with an ODBC connection to a PostgreSQL server.
The answer to my query takes a very long time to come to to my
workstation. My investigations led me to think that the problem
lies within my workstation's TCP/IP stack (i.e. the query runs
very fast and all other workstations on my network).
I have made an ethereal log in which I witness something very
strange : there is a very long delay (>0.15s) between packets and
ACK, every 15 packets (approximatively).
My knowledge of TCP/IP is quite limited, and I do not understand
where this delay comes from.
Could someone here have a look at this log and tell me why there
is such a delay, and maybe how I could fix this issue ?
Thanks a lot for your help !
Regards
--
Arnaud
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users