On Sun, 23 Feb 2003, Giorgos Keramidas wrote:
> On 2003-02-22 20:05, Andre Guibert de Bruet <[EMAIL PROTECTED]> wrote:
> > > I noticed the same thing... then
> > >
> > > <maxim> try sysctl net.inet.tcp.delayed_ack=0
> > >
> > > fixed the issue
> >
> > That worked. Shouldn't this sysctl be turned off by default?
>
> Nah. Not really. Delaying acks can save quite a lot of of bandwidth
> for bulk data transfers.
Having read up on the issue, I can understand the reasoning for wanting
delayed_ack on by default.
>From tuning(7):
With delayed acks turned off, the acknowledgement
may be sent in its own packet, before the remote service has a chance to
echo the data it just received. This same concept also applies to any
interactive protocol (e.g. SMTP, WWW, POP3), and can cut the number of
tiny packets flowing across the network in half. The FreeBSD delayed ACK
implementation also follows the TCP protocol rule that at least every
other packet be acknowledged even if the standard 100ms timeout has not
yet passed. Normally the worst a delayed ACK can do is slightly delay
the teardown of a connection, or slightly delay the ramp-up of a slow-
start TCP connection.
I find myself waiting up to two seconds for data to flush to the terminal
on a 28 line 'ls -l'. net.inet.tcp.delayed_ack doesn't appear to cause
this behavior on 4.7-stable. Did we inadvertently break the 100ms clause
with the latest TCP patches?
Regards,
> Andre Guibert de Bruet | Enterprise Software Consultant >
> Silicon Landmark, LLC. | http://siliconlandmark.com/ >
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
