Date: Fri, 30 May 1997 16:01:00 +0900 From: Kenjiro Cho <kjc@csl.sony.co.jp> To: Chris Csanady <ccsanady@friley01.res.iastate.edu> Cc: hackers@FreeBSD.ORG Subject: Re: TCP/IP bug? Unnecessary fragmentation... Message-ID: <199705300701.QAA12323@hotaka.csl.sony.co.jp> In-Reply-To: Your message of "Thu, 29 May 1997 15:44:30 EST." <199705292044.PAA04544@friley01.res.iastate.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Chris Csanady <ccsanady@friley01.res.iastate.edu> said: >> Another oddity is that if you close the connection immediately, for the >> same data sizes that it does this odd fragmentation (100 < S < 208), >> the FIN is piggybacked on the 2nd data segment. This doesn't happen >> with any other data size. >> I have some graphs, and I believe that it does it at many other sizes too. >> The performance hit is _much_ more that just mbuf/cluster handling should >> impose it would seem. It seems to do it up around 2000, 2100(?), 4000... >> Is this a generic 44BSD problem, or is it FreeBSD specific? It is not a bug but caused by a mismatch of the mbuf allocation and TCP, which is common to *BSD systems. The mbuf allocation algorithm is that if the data size is less than 2 MLENs (100 bytes for the first one, 108 bytes otherwise), allocate 2 mbufs. If the data size is larger than 2 MLENs, allocate a 2KB mbuf cluster. So, 2 small mbufs will be allocated when you send: 100 < len <= 208 or n * 2K + 108 < len <= n * 2K + 216 tcp_usr_send is called for each mbuf. The Nagle algorithm of TCP prevents the sender from sending a small packet when outstanding packets have not yet been acknowledged. Thus, the 2nd packet won't be sent until the ack of the 1st packet comes back. To make matters worse, the ack of the 1st packet will be delayed up to 200ms on the receiver side by the delayed ack mechanism. I think, considering the wide use of TCP, the socket layer should try to call tcp_usr_send all at once when possible. --kj
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199705300701.QAA12323>