Date: Wed, 1 May 96 20:23:56 +0000 From: Andrew.Gordon@net-tel.co.uk To: careilly@ios.internet-ireland.ie Cc: hackers@FreeBSD.org Subject: Re: Really slow network transfer rates. Message-ID: <"13718-960501202428-5C71*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/"@MHS> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 <netinet/tcp.h> in the ifdef FreeBSD section of includes.h.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?"13718-960501202428-5C71*/G=Andrew/S=Gordon/O=NET-TEL Computer Systems Ltd/PRMD=NET-TEL/ADMD=Gold 400/C=GB/">