On Sun, Dec 30, 2007 at 08:25:19PM +1100, mufurcz wrote: > johan beisser wrote: > > > >Fewer frames get corrupted, means less processing overhead per frame. > Not true at all - if only the payload is changed.
Use NICs capable of TCP checksumming and the appropriate drivers, that will mean less processing for your CPUs. > >Outside of that, the remaining advantage is fewer frames going over > >the line. > But the same amount of data(!) needs to be transmitted, and only if > no collision(s) and retransmission(s) occurs! Anybody on the same > LAN segment - who wants to transmit, will have to wait (be on hold) > until the payload gets through. Still using hubs? Fight for a budget increase if this is the case. > >It's not recommended on the same LAN as systems not using jumbo frames. > I know only a few HP routers which can handle efficiently jumbo > frames (internally) - IF enabled. Ask yourself, what would happen > with this jumbo frames outside a LAN segment? How would the rest of > routers/switches/repeaters - like hubs/etc. would handle jumbo > frames? A router in between jumbo and non-jumbo will break frames down to non-jumbo sizes if need be. Even a wee Cisco 3750G we tested with does so with minimal CPU hit (maybe it's done in hardware on those, I don't know) We had problems when using is on the same segment with 1518 MTUs. Much of what we read recommened against it but that's like sticking a "DO NOT PUSH" sign above a big red button for me. :) Anyhow to sum it up: jumbo is cool when used correctly. The throughput difference can be quite impressive, we had a considerable boost in speed on 4x GigE iSCSI RAID chassis to the front end box and with NFS. gg
