farr_at_metservice.com wrote:
> At 08:23 AM 3/12/2004, you wrote:

[...]

>>> Perhaps you can help ... the following 3 steps happen really fast
>>> (within 3ms or so) according to ethereal
>>> STOR filename
>>> 150 Accepted data connection
>>> two packets of data going to server and being acked straight away,
>>> the last packet is the last packet of data for that file.
>>> tcp control packet sent to server
>>> tcp control packet recieved form server
>>> tcp control packet sent to server
>>> now we get a long pause of any where from 120ms to 200ms then a
>>> message from the client box port (which seems to be the same for each
>>> file in the transfer set) to ftp on the server ... it looks like
>>> this in ethereal
>>> 3044 > ftp [ACK] Seq=327186750 Ack=2387512526 Win=63626 Len=0 (60
>>> bytes of control data)
>>> Response 226-32456.2 Mbytes of free disk space
>>> etc with everything going really fast again
>>> So it looks like there is a packet being sent to the server that is
>>> being ignored ... and this is causing a delay between the end of one
>>> file and the start of the next.
>>
>> Can you post the actual ethereal output?
>
> It is attached as a libpcap file. If that is not enough I will send it
> directly to you ...

It looks like the delay you see is due to TCP's delayed ACK feature.
It's hard to be certain from the output, but the timing seems to fit.
The delayed ACK feature holds a pending ACK segment in the hope that
some data will arrive within some amount of time (typically 50 - 200 ms)
which it can piggyback the ACK on top of. If that doesn't happen the ACK
will be sent when the timer expires.

I don't know if there's a standard way to turn that off, but your OS may
have some mechanism to do so if you really want to (it probably will
turn it off for the whole system though).

At any rate, this looks like a TCP issue to me rather than a curl issue.

Joe
Received on 2004-03-11