Date: Tue, 20 Sep 2016 01:08:12 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Lyndon Nerenberg <lyndon@orthanc.ca> Cc: "Dean E. Weimer" <dweimer@dweimer.net>, FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: LAGG and Jumbo Frames Message-ID: <20160919220812.GG2960@zxy.spb.ru> In-Reply-To: <alpine.BSF.2.20.1609191419030.93154@orthanc.ca> References: <48926c6013f938af832c17e4ad10b232@dweimer.net> <alpine.BSF.2.20.1609191326280.93154@orthanc.ca> <04c9065ee4a780c6f8986d1b204c4198@dweimer.net> <alpine.BSF.2.20.1609191419030.93154@orthanc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 19, 2016 at 02:28:56PM -0700, Lyndon Nerenberg wrote: > > Everything on physical Ethernet has support for it Including the LAN > > interface of Firewall, and talks to it just fine over a single interface with > > Jumbo frames enabled. > > Well, before you get too carried away, try this: > > 1) Run a ttcp test between a pair of local hosts using the exiting > jumboframes (pick two that you expect high volume traffic between). > > 2) Run the same test, but with the default MTU. > > If you don't see a very visible difference in throughput (e.g. >15%), it's > not worth the hassle. > > Just as a datapoint, we're running 10-gigE off some low-end Supermicro > boxes with 10.3-RELEASE. Using the default MTU we're getting > 750 MB/s > TCP throughput. I can't believe that you won't be able to fully saturate > a 1 Gb/s link running the default MTU on anything with more oomph than a > dual-core 32-bit Atom. > > IOW, don't micro-optimize. Life's too short ... May be surprised, but jumbo frames can degrade performance for not direct connected host, i.e. multiple switch between host: [hostA]=[SW1]=[SW2]=[SW3]=[hostB] This is because RTT of this link for jumbo frames higher 1500 bytes frame for store-and-forward switch chain.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160919220812.GG2960>