From owner-freebsd-hackers Wed Aug 12 04:47:32 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id EAA18059 for freebsd-hackers-outgoing; Wed, 12 Aug 1998 04:47:32 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from bsd.synx.com (rt.synx.com [194.167.81.239]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id EAA17983 for ; Wed, 12 Aug 1998 04:46:58 -0700 (PDT) (envelope-from root@synx.com) Received: from synx.com (rn [192.1.1.241]) by bsd.synx.com (8.6.12/8.6.12) with ESMTP id MAA01217; Wed, 12 Aug 1998 12:44:03 +0100 Message-Id: <199808121144.MAA01217@bsd.synx.com> Date: Wed, 12 Aug 1998 13:43:58 +0200 (CEST) From: Remy NONNENMACHER Reply-To: remy@synx.com Subject: Re: network problem with FreeBSD/Yard (yardnetd) To: didier@omnix.net cc: support@yard.de, hackers@FreeBSD.ORG In-Reply-To: MIME-Version: 1.0 Content-Type: TEXT/plain; CHARSET=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 12 Aug, Didier Derny wrote: > Hi, > > I've a strange problem with yard. > ..... > B/ Solution ? > ------------- > > 1/ I suppose that a setsockopt(socket... TCP_NODELAY..) > would have the same result for the yard application if it was > inserted in the yard code ? > no, TCP_NODELAY allows your local stack to immediatly send packets to peer without waiting for a ack. It's also called the Nagle algo. It is intented for applications sending a lot of small packets. Delaying send in this case is good since it allows the local stack to accumulate data and build bigger pakets. > 2/ what are the implication of setting ...ack_delayed=0 for the system ? > Delayed ack is the exact opposite. It allows the receiving side to delay acking received packets with the hope that a flowing back data (like a response to a query) would transports a piggy-backed ack. > 3/ What should I say to Yard to have this problem solved ? > Delayed ack and nagle are two solutions that must *NEVER* be face to face !!. Many programs uses TCP_NODELAY to turn off Nagle. In the worst case, (Nagle and delayed ack on, and depending on the behaviour of the flow), you can have each send delayed and each ack delayed. This means that your wonderfull 100Mb/s switched network can work as low as 1kb/s !!. Many programs uses the TCP_NODELAY to turn off Nagle. It's sufficient for communications where the receiving side immediatly send back a data packet. This doesn't correctly solves the problem for a one direction flow case. ack-delayed=0 using sysctl (or a '#define TCP_ACK_HACK' at beginning of tcp_input.c for old versions of 3.0) will turn off delayed ack. Even with Nagle on at the other side, this will greatly help since packet sending delaying will be limited only by the (flowing back ack) network roundtrip. The best performance is achieved this a carefull selection of what side uses what algorithm depending on the typical data flow. You can safely turn all two off if you have no problem of amount of packets exchanged. Only remember that delayed ack and Nagle off means that every packet will mostly generate an empty ack one. this can easily double the number of exchanges. As a rule of thumb, Nagle is interesting when you have very small packets flowing on one direction (ie: a badly written program that do a lot of small write()) and delayed-ack is interesting when the receiving side immediatly sends back a data packet in response (ie: an encapsulated protocol). Good luck. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message