RE: jumbo frames

["Richard A. Steenbergen" <ras () e-gerbil net>]

On Thu, Apr 26, 2001 at 12:12:33PM -0700, Roeland Meyer wrote:
> This depends on the type of traffic. We use it to enhance performance
> of the data tier. We've jiggered the TCP/IP stacks for ~4500 byte
> packets and have knee-capped the slow-start algorithm (which doesn't
> make sense in a pure switched environment anyway). What we then wind
> up with, is a dedicated data LAN between our application servers and
> the Oracle database servers. It comes out to about an order of
> magnitude increase in performance and SQL query responsiveness. At
> first we went to jumbo packets. We saw such a radical improvement that
> we started investigating and found the slow-start issue. Jumbo packets
> are one way around the slow-start problem if you can't jigger the
> stack itself. Most of the queries are reasonably short so we saw some
> serious improvements by killing the slow-start. If you can modify your
> IP stack then it still pays to use jumbo packets because you reduce
> the overhead on the wire.

OS tip of the day:

If you run FreeBSD, check out sysctl net.inet.tcp.slowstart_flightsize.
This lets you set a multiple for the initial window size and can be very
beneficial for servers which do lots of quick start/stop transfers over
TCP. I suspect this was much more useful to you then jumbo frames in that
application.

And on an unrelated note I have a mirror of the Because ICANN swf at
http://www.e-gerbil.net/ras/video/icannstage.swf, and I'd like to thank
the creators for not including any AYB references... We now return you to
your regularly scheduled "can someone from the globix noc in botswana call
me about my t1"... :P

-- 
Richard A Steenbergen <ras () e-gerbil net>       http://www.e-gerbil.net/ras
PGP Key ID: 0x138EA177  (67 29 D7 BC E8 18 3E DA  B2 46 B3 D8 14 36 FE B6)