[4168] in linux-net channel archive
Re: TCP/buffering changes
daemon@ATHENA.MIT.EDU (Alan Cox)
Fri Aug 23 20:14:40 1996
From: alan@lxorguk.ukuu.org.uk (Alan Cox)
To: dcrane@ivs.piedmont.net (Darren Crane)
Date: Sat, 24 Aug 1996 00:31:00 +0100 (BST)
Cc: alan@lxorguk.ukuu.org.uk, linux-kernel@vger.rutgers.edu,
linux-net@vger.rutgers.edu, torvalds@cs.helsinki.fi
In-Reply-To: <Pine.LNX.3.95.960823135907.247A-100000@ivs.piedmont.net> from "Darren Crane" at Aug 23, 96 02:04:55 pm
> Something between 2.0.10 and 2.0.11 slowed samba down.
Thanks.
> Why a SO_SNDBUF of 4k? 90% of trafic is from our home grown dos app
> which reads files in 4K chunks. Why? Cause Dos sucks. But the slowdown
In which case your SO_SNDBUF should be well over 4K (eg 8K or 16K). 4K will
not allow you to queue 4K due to buffer overhad.
> I experience happens with regular dos copy commands as well, and it still
> exists if I up the SO_SNDBUF to 32768 (or anything between the two).
Ok.
2.0.11 changes the kernel to wait differently for memory when doing large
block ouput operations, and also has a change to fix the MSS handling when
a remote offers an initial 0 byte window.
Can you build and try the following 2 kernels.
1. 2.0.11 with the net/core/sock.c net/core/sock.c net/ipv4/tcp.c
net/ipv4/tcp_input.c of 2.0.10
This kernel is 2.0.11 without the buffer handling changes. If its the
buffer handling/tcp causing the problem then this kernel should be as
fast as 2.0.10
2. 2.0.10 with the files quoted above from 2.0.11
This one should be slow.
In the meantime I shall go and take the buffering code apart to look for
any fencepost errors.
Alan
