Re: delayed ACK

2002-10-17 Thread Oleg Polyakov
--- Steve Francis <[EMAIL PROTECTED]> wrote: > Lars Eggert wrote: > > >Paul Herman wrote: > > > > > >>Not true. Although some bugs have been fixed in 4.3, FreeBSD's > >>delayed ACKs will still degrade your performance dramatically in > >>some cases. > >> > >> > > > >I'm sorry, but such st

Re: delayed ACK

2002-10-15 Thread Mike Silbersack
On Tue, 15 Oct 2002, Luigi Rizzo wrote: > On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote: > ... > > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but > > maybe we need to do something similar. > > this helps you if the other side has delayed acks, but halv

Re: delayed ACK

2002-10-15 Thread Luigi Rizzo
On Tue, Oct 15, 2002 at 08:52:49PM -0500, Mike Silbersack wrote: ... > NetBSD introduced a "fix" for this recently, it seems sorta hackish, but > maybe we need to do something similar. this helps you if the other side has delayed acks, but halves the throughput if you are being window limited and

Re: delayed ACK

2002-10-15 Thread Mike Silbersack
On Tue, 15 Oct 2002, Luigi Rizzo wrote: > this smells a lot as a bad interaction between default window > size and mtu -- loopback has 16k default, maybe tar uses a > smallish window (32k is default now for net.inet.tcp.sendspace, > but used to be 16k at the time), which means only 1 or 2 packet

Re: delayed ACK

2002-10-15 Thread Luigi Rizzo
this smells a lot as a bad interaction between default window size and mtu -- loopback has 16k default, maybe tar uses a smallish window (32k is default now for net.inet.tcp.sendspace, but used to be 16k at the time), which means only 1 or 2 packets in flight at once, meaning that many times you g

Re: delayed ACK

2002-10-15 Thread Paul Herman
On Tue, 15 Oct 2002, Lars Eggert wrote: > Paul Herman wrote: > > > > Not true. Although some bugs have been fixed in 4.3, FreeBSD's > > delayed ACKs will still degrade your performance dramatically in > > some cases. > > I'm sorry, but such statements without a packet trace that exhibits the > p

Re: delayed ACK

2002-10-15 Thread Lars Eggert
Steve Francis wrote: >> > He's probably referring to poorly behaved windows clients, on certain > applications, if you leave net.inet.tcp.slowstart_flightsize at default. Ah. Well, that's a Windows problem :-) > Incidentally, why are not the defaults on > net.inet.tcp.slowstart_flightsize high

Re: delayed ACK

2002-10-15 Thread Steve Francis
Lars Eggert wrote: >Paul Herman wrote: > > >>Not true. Although some bugs have been fixed in 4.3, FreeBSD's >>delayed ACKs will still degrade your performance dramatically in >>some cases. >> >> > >I'm sorry, but such statements without a packet trace that exhibits the >problem are just n

Re: delayed ACK

2002-10-15 Thread Lars Eggert
Paul Herman wrote: > > Not true. Although some bugs have been fixed in 4.3, FreeBSD's > delayed ACKs will still degrade your performance dramatically in > some cases. I'm sorry, but such statements without a packet trace that exhibits the problem are just not useful. Lars -- Lars Eggert <[EM

Re: delayed ACK

2002-10-15 Thread Paul Herman
On Mon, 14 Oct 2002, Steve Francis wrote: > Kirill Ponomarew wrote: > > > > is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with > > heavy network traffic ? > > > If you want to increase your network traffic for no particular reason, > and increase load on your server, then ye

Re: delayed ACK

2002-10-14 Thread Steve Francis
Kirill Ponomarew wrote: > Hi, > > is it recommended to use net.inet.tcp.delayed_ack=0 on the machines with > heavy network traffic ? > If you want to increase your network traffic for no particular reason, and increase load on your server, then yes. Otherwise no. To Unsubscribe: send mail to