Date: Mon, 19 Sep 2016 14:28:56 -0700 (PDT) From: Lyndon Nerenberg <lyndon@orthanc.ca> To: "Dean E. Weimer" <dweimer@dweimer.net> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: LAGG and Jumbo Frames Message-ID: <alpine.BSF.2.20.1609191419030.93154@orthanc.ca> In-Reply-To: <04c9065ee4a780c6f8986d1b204c4198@dweimer.net> References: <48926c6013f938af832c17e4ad10b232@dweimer.net> <alpine.BSF.2.20.1609191326280.93154@orthanc.ca> <04c9065ee4a780c6f8986d1b204c4198@dweimer.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 ... --lyndon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1609191419030.93154>