|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: jumbo frames
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 <[email protected]> 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)
|