Re: [Ethereal-users] Help interpreting log file ?

["Bill Meier" <wmeier@xxxxxxxxxxx>]

Arnaud Lesauvage wrote:

> 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).


>From a quick look at the file I strongly suspect that the problem 
you are encountering is the same as one I've encountered.

The short answer: 

"TCP_NODELAY" should be enabled on the TCP connection to
the database on both the client and server side of the connection.
(This is also known as "disabling the Nagle Algorithm").
(Based upon your capture I can almost guarantee that TCP_NODELAY is
*not* enabled on your Database TCP connection on the server side).

The use of TCP_NODELAY is a database option for a different database server with 
which I'm familiar. I suggest you consult your DBA with respect to PostgreSQL.
(Also Google "database tcp_nodelay" & etc for information).

The longer answer:

Delays may be observerd in client/server query/response types 
of applications over a TCP connection with the Nagle Algorithm enabled.

The presence or absence of a delay is dependent upon the length of 
the query and/or the query response; this causes much confusion when trying
to analyze delay problems because the delays will seem to "come and go" 
depending upon the exact length of the query and/or response.

There is also much confusion as to the exact nature of the problem.

I believe the current edition of Stevens' "TCPIP Illustrated" gives a pretty clear
explanation of the issue.


The details in your case:

I believe that due to the Nagle Algorithm, for the specific query reponse 
shown in the capture, each time your server sends a "short" packet, 
the server waits for an ACK from the client before sending the next packet.
In your case, the server application is sending the response in chunks of 
8192 data bytes which results in a "short" packet every 6 packets).

(I would suspect that a capture of a query/response from one of the
workstations on which the query runs "very fast" may show that the query response 
is of a different length).


Bill Meier