When performing an FTP transfer, a delay can be incurred between two
consecutive messages from the server to the client, perhaps due to Nagle or
slow start. For example:
Client Server
1 RETR file --------------->
2 <------------ Transfer starting
3 (transfer occurs on another socket)
4 <------------ Transfer completed
The problem is that the server’s TCP stack doesn’t send message #4 until
some delay has elapsed, although it’s not clear whether it needs the ACK
from #2 due to slow start or is waiting for the Nagle delay.
If many small files (or directory listings) are transferred in succession,
the process runs many times slower than it could.
This same problem occurs on Microsoft IIS5, but it does NOT occur on a Linux
(RedHat 9) system that was tested. If it’s as simple as having the FTP
daemon set NODELAY on the socket, is such an option available, either
through ftpd or inetd? (And, if not, could it be added, please?)
Thanks,
lew
Which is QNX6 the client or the server? Does it happen
if both are QNX6?
-seanb
Lewis Donzis <lew@perftech.com> wrote:
When performing an FTP transfer, a delay can be incurred between two
consecutive messages from the server to the client, perhaps due to Nagle or
slow start. For example:
Client Server
1 RETR file ---------------
2 <------------ Transfer starting
3 (transfer occurs on another socket)
4 <------------ Transfer completed
The problem is that the server’s TCP stack doesn’t send message #4 until
some delay has elapsed, although it’s not clear whether it needs the ACK
from #2 due to slow start or is waiting for the Nagle delay.
If many small files (or directory listings) are transferred in succession,
the process runs many times slower than it could.
This same problem occurs on Microsoft IIS5, but it does NOT occur on a Linux
(RedHat 9) system that was tested. If it’s as simple as having the FTP
daemon set NODELAY on the socket, is such an option available, either
through ftpd or inetd? (And, if not, could it be added, please?)
Thanks,
lew
“Sean Boudreau” <seanb@qnx.com> wrote in message
news:ccgq4p$h0a$1@inn.qnx.com…
Which is QNX6 the client or the server? Does it happen
if both are QNX6?
QNX6 is the server. The client is Win2k in every case. When the server is
Win2k or QNX6, the delay is there, but if it’s RedHat 9, no delay.
I’ll try a QNX6 client and let you know, although it won’t help if it
performs differently. In this application, the client will always be a
Windows PC.
lew
How long a delay? 100ms? 500ms? 1 second?
If it’s in the 500ms range, you may well be seeing
the delayed ACK problem. Longer, and it’s something else.
John Nagle
Lewis Donzis wrote:
When performing an FTP transfer, a delay can be incurred between two
consecutive messages from the server to the client, perhaps due to Nagle or
slow start. For example:
Client Server
1 RETR file ---------------
2 <------------ Transfer starting
3 (transfer occurs on another socket)
4 <------------ Transfer completed
The problem is that the server’s TCP stack doesn’t send message #4 until
some delay has elapsed, although it’s not clear whether it needs the ACK
from #2 due to slow start or is waiting for the Nagle delay.
If many small files (or directory listings) are transferred in succession,
the process runs many times slower than it could.
This same problem occurs on Microsoft IIS5, but it does NOT occur on a Linux
(RedHat 9) system that was tested. If it’s as simple as having the FTP
daemon set NODELAY on the socket, is such an option available, either
through ftpd or inetd? (And, if not, could it be added, please?)
Thanks,
lew
“John Nagle” <nagle@downside.com> wrote in message
news:cch6c5$q8c$1@inn.qnx.com…
How long a delay? 100ms? 500ms? 1 second?
If it’s in the 500ms range, you may well be seeing
the delayed ACK problem. Longer, and it’s something else.
It’s averaging about 190ms.
lew
Lewis Donzis wrote:
“John Nagle” <> nagle@downside.com> > wrote in message
news:cch6c5$q8c$> 1@inn.qnx.com> …
How long a delay? 100ms? 500ms? 1 second?
If it’s in the 500ms range, you may well be seeing
the delayed ACK problem. Longer, and it’s something else.
It’s averaging about 190ms.
Just a guess, since I expierienced this some years ago (with QNX4, though)
Did you switch the Windows-FTP-client to ‘binary’? Using ‘ascii’
transmission slows the data rate extremly down.
(but I never tracked that deeper …)
\
Karsten P. Hoffmann <karsten.p.hoffmann@web.de>
“I love deadlines. I especially like the whooshing sound
they make as they go flying by.”
[In memoriam Douglas Adams, 1952-2001]