Date: Wed, 24 Jan 2001 20:50:06 +0100 (CET) From: Paul Herman <pherman@frenchfries.net> To: Jonathan Lemon <jlemon@flugsvamp.com> Cc: <net@freebsd.org> Subject: Re: I have delayed ACK problems Message-ID: <Pine.BSF.4.32.0101241854420.21262-100000@husten.security.at12.de> In-Reply-To: <200101241721.f0OHL2627523@prism.flugsvamp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Jonathan, On Wed, 24 Jan 2001, Jonathan Lemon wrote: > >10:49:54.279497 16.1035 > 10.40438: . ack 19433 win 17520 (DF) > >10:49:54.371025 16.1035 > 10.40438: . ack 21481 win 17520 (DF) > > Are you sure the trace has delayed ack turned off? Sorry, wasn't clear there. Yes, this trace is with delayed acks turned ON, exhibiting the performance problems I was describing. > Try bumping up net.inet.tcp.slowstart_flightsize, which specifies > how many packets can be outstanding (unacked) at the beginning > of a TCP connection. Do you mean lower? Then it wouldn't wait for more segments to arrive and run up the delayed ack timer, correct? Thanks, I'll try it out (both ways, higher & lower values) but this unfortunately seems like a workaround rather than a solution. Something just doesn't sit well me. This shouldn't happen in a 100Mbit LAN. This seems like a plain vanilla network transaction, and FreeBSD is failing on something, where other OSes in the same environment don't. Time to dig through sys/netinet/tcp* ... -Paul. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.32.0101241854420.21262-100000>