[29353] in North American Network Operators' Group
RE: Jumbo Frames (was Re: MAE-EAST Moving? from Tysons corner toreston VA. )
daemon@ATHENA.MIT.EDU (Roeland M.J. Meyer)
Mon Jun 19 12:53:27 2000
Reply-To: <rmeyer@mhsc.com>
From: "Roeland M.J. Meyer" <rmeyer@mhsc.com>
To: <sthaug@nethelp.no>
Cc: <ras@e-gerbil.net>, <michael.dillon@gtsip.net>, <nanog@merit.edu>
Date: Mon, 19 Jun 2000 09:51:01 -0700
Message-ID: <010401bfda0e$8d0eadd0$eaaf6cc7@PEREGRIN>
MIME-Version: 1.0
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In-Reply-To: <52102.961431924@verdi.nethelp.no>
Errors-To: owner-nanog-outgoing@merit.edu
> sthaug@nethelp.no: Monday, June 19, 2000 9:25 AM
> > Actually, my testing shows a falure to utilize even 100baseTX
> > fully. Even in a switched FDX environment (no collisions) I
can't
> > achieve line rate without bumping the packet size up.
Considering
> > that the smallest box is a quad-CPU SMP machine (550Mhz), I
don't
> > think that there is a CPU shortage <grin>.
>
> The your problem probably lies elsewhere. A decent operating
system
> (e.g. FreeBSD) can do line rate on 100baseTX with something
along the
> line of a Pentium-166. Not exactly a very powerful machine by
current
> standards. (And btw this was measured three years ago...)
Steinar,
I should have re-caveated, for your benefit. I am not testing
with a bazillion-byte file. I am testing with query/response
against a RDBMS host. IOW, a typically real-world(tm) practical
application. The responses range from 3-50KB, with anomalies out
to 100KB. The slow-start algorithm has been identified as the
real culprit. Not wanting to carve up all the IP stacks, I bump
MTU up to effectively reduce the impact of the slow-start
algorithm (which is obsolete in a switched environment anyway,
worse than useless). Measurments are taken at the RDBMS host, as
well as the client.
