Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 22 Feb 2003 22:49:40 -0500 (EST)
From:      Andre Guibert de Bruet <andy@siliconlandmark.com>
To:        Giorgos Keramidas <keramida@ceid.upatras.gr>
Cc:        Erik Greenwald <erik@smluc.org>, current@FreeBSD.ORG
Subject:   Re: SSH (TCP?) lag
Message-ID:  <20030222220054.C34711@alpha.siliconlandmark.com>
In-Reply-To: <20030223025707.GE88377@gothmog.gr>
References:  <20030222100441.Y34711@alpha.siliconlandmark.com> <20030222125817.A15590@xarx.midsouth.rr.com> <20030222200117.E34711@alpha.siliconlandmark.com> <20030223025707.GE88377@gothmog.gr>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Feb 2003, Giorgos Keramidas wrote:

> On 2003-02-22 20:05, Andre Guibert de Bruet <andy@siliconlandmark.com> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030222220054.C34711>