Date: Thu, 13 Aug 1998 13:08:03 +0200 (CEST) From: Remy NONNENMACHER <remy@synx.com> To: didier@omnix.net Cc: support@yard.de, hackers@FreeBSD.ORG Subject: Re: network problem with FreeBSD/Yard (yardnetd) Message-ID: <199808131108.MAA03143@bsd.synx.com> In-Reply-To: <Pine.BSF.3.96.980812223139.23123A-100000@omnix.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12 Aug, Didier Derny wrote: > On Wed, 12 Aug 1998, Remy NONNENMACHER wrote: > >> >> 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. >> > > I did some testing with the ...ack_delayed=1 (not modified) > and with the TCP_NODELAY forced in tcp_output.c (horrible hack) > > I obtained the same result and the database was really fast > so, TCP_NODELAY could at least be a work around if Yard compiled a version > of their program with this flag set. > (actually the database is unusable 1 raw/s [without any hack]) > but I'm not sure if it's the best solution > > By the way, I aslo did some testing with tcpblast on the loopback > > with ...ack_delayed=1 and without my awful hack on TCP_NODELAY > I get a repeateable 30Mbs/s > MBytes/s, i suppose. > with ..ack_delayed=0 or the hack I get a very irregular result going from > 2 to 30 Mb/s > That's due to the fact that tcpblast uses the discard service so data flows only on one direction. NODELAY=0 and delayed_ack=1 give you the best performance in that case because pushing a lot of data onto the socket forces sending of concatenated data and, on the other side, acks are generated quickly for big amounts of data. (also note that disabling delayed_ack forces the peer to send a ack for each PUSHed packet, that is the case for each write() with NODELAY. In that case you can consider that setting NODELAY on the sender side also (partially) controls the ack delaying on the other side) The situation would be the opposite if, for example, you send 5 paquets of 50 bytes (5 write(), creating two physical packets), then wait for a response..... (may be the case for your DB). Once again, getting the two parameters the right value needs: - a good knowledge of the flow behaviour (between client and server) and preferably: - a client/server software behaving always the same way. (ie, not something like 50% ping/pong and 50% one way) Also remind that getting 98Mb/s for 10% of the time and 10Mb/s for 90% is worst than having always 50Mb/s About the sanity of hacking NODELAY in the kernel, hum, well, imagine yourself with a proprietary Unix and no possibility to have the TCP_NODELAY engraved in the application.....you could die of that !! (i know: i saw bodies..;). RN. (BTW, this is interesting. I will spend one day writting a little client/server tools to test all best/worst behaviour i already encountered). Bonne journee. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199808131108.MAA03143>