From owner-freebsd-hackers Wed May 1 13:27:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id NAA16740 for hackers-outgoing; Wed, 1 May 1996 13:27:04 -0700 (PDT) Received: from eldorado.net-tel.co.uk (eldorado.net-tel.co.uk [193.122.171.253]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id NAA16719 for ; Wed, 1 May 1996 13:26:55 -0700 (PDT) From: Andrew.Gordon@net-tel.co.uk Received: (from root@localhost) by eldorado.net-tel.co.uk (8.6.12/8.6.10) id VAA00183; Wed, 1 May 1996 21:25:26 +0100 X400-Received: by mta "eldorado" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 1 May 96 21:23:58 +0100 X400-Received: by mta "net-tel cambridge" in "/PRMD=net-tel/ADMD=gold 400/C=gb/"; Relayed; Wed, 1 May 96 20:23:56 +0000 X400-Received: by "/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"; Relayed; Wed, 1 May 96 20:23:56 +0000 X400-MTS-Identifier: ["/PRMD=NET-TEL/ADMD=Gold 400/C=GB/";hst:21237-960501202356-16B9] X400-Content-Type: P2-1984 (2) X400-Originator: Andrew.Gordon@net-tel.co.uk Original-Encoded-Information-Types: IA5-Text X400-Recipients: non-disclosure:; Date: Wed, 1 May 96 20:23:56 +0000 Content-Identifier: Re: Really slow Message-Id: <"13718-960501202428-5C71*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> To: careilly@ios.internet-ireland.ie Cc: hackers@FreeBSD.org In-Reply-To: <"SunOS:29771-960501174438-2FB8*/DD.RFC-822=owner-hackers(a)FreeBSD.org/O=internet/PRMD=NET-TEL/ADMD=GOLD 400/C=GB/"@MHS> Subject: Re: Really slow network transfer rates. Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk > Problem: I am suffering from ethernet tranfer rates of 6.5kps between > machines on the same ethernet. There are 5 FreeBSD boxes involved. Win95 > boxes on the same network get normal transfer rates between themselves but > slow to the UNIX boxes. Ping times to all the machines are fine, telnet > performance is fine. Any sustained transfer slows down to 6.5kps. If your setup is: 1) The file transfer application is SAMBA 2) The client machines are faster than the server (in my case, a P90 server, and all clients were working fine apart from a new P120 which was much slower than the 486s about the place). then I can tell you what the problem is. A TCP connection exists between client and server, and each filesystem operation involves a request block being sent from client to server and a result block coming back. Since the application running on the client is typically doing a series of read() calls, the next request won't be sent until the previous result has been completely received. Unfortunately, a typical read() of a couple of K is an uncomfortable size for TCP flow control, and Samba makes things worse by writing it on the socket in multiple chunks. If the client machines are nice and slow, the entire result gets generated into socket buffers on the server and goes out in full-length packets. However, if the client is very quick off the mark and has acknowledged the first packet or two before the whole result has been generated, it can get split into not-full packets and the Nagle algorithm can come into play on the last packet of the transaction. Since there is no data flowing in the opposite direction a! t that moment, this packet gets stalled until the client's TCP delayed acknowledge timeout. Hence you end up doing only a few transactions per second. The fix is to use the -O TCP_NODELAY option to smbd (which duly disables the Nagle algorithm). Note that this option was broken in the FreeBSD Samba port at the time I discovered this (about 9 months ago) - if it's still broken, the problem was a missing #include in the ifdef FreeBSD section of includes.h.