Start a Conversation

Unsolved

This post is more than 5 years old

1963

February 15th, 2012 17:00

Jumbo Frames in ndmp backup

Hi all

Anyone have good experience enabling jumbo frame and performance gained?

1) Some forum mentions that if jumbo frame enabled, all the clients in that VLAN must be enabled as well, is this correct?

2) Jumbo frame is enabled on network switch side or NIC or both? what is the parameter?

3) Enabled on all? = SN/Client/Backup Servers/Celerra/DD ?

4) Any known cons by enabling this?

Looks like EMC backs off on this topic...but in the Perf Guide guide, they recommend it...but lack of info

https://solutions.emc.com/emcsolutionview.asp?id=esg54032

Jumbo frames

It is recommended to use jumbo frames in environments capable of handling them. If

both the source, the computers, and all equipment in the data path are capable of

handling jumbo frames, increase the MTU to 9 KB.

These examples are for Linux and Solaris operating systems:

◆ Linux: ifconfig eth0 mtu 9000 up

◆ Solaris: Use the following command to configure jumbo frames for an nxge

device:

ndd -set /dev/nxge<#> accept-jumbo 1

where <#> is replaced with the driver instance number.

Note: To determine the instance number of a following device, run the command nxge /etc

/path_to_ins

Is Windows supported?

Thanks folks...

5 Practitioner

 • 

274.2K Posts

February 21st, 2012 02:00

The handling of jumbo frames is down to the data link layer, and is handled well below any component that the applications have a clue about.  If you can enable jumbo frames on all networking equipment involved, there should be no issues.  If you can't.... there should be no issues, as the networking protocols should simply negotiate to the highest performing level of all components involved (note the "should" - this should be part of the firmware, which is coded in software and can still have bugs).  EMC will back off on this as.... I'm fairly certain I'm right in saying that we buy in all networking hardware and won't have any control over this whatsoever.  Might as well recommend to use the highest available networking speed.

I very much doubt that this will need to be set on every client in a VLAN.  I have no direct experience here, but AFAIC the hardware involved will negotiate an appropriate MTU size.  If it's set too high for one and everything breaks, then systems with the high MTU would probably also fail to access the internet. 

Again, having no direct experience setting this, I expect it will need to be set on the NICs only.  I would be surprised if it needs to be enabled on the switch side as these don't initiate connections.  If they handle jumbo frames then they should simply use them, or negotiate to the max frame size for the switch if not.

Since this will be used for communications between computers, it would need to be set on each system involved to have any significant impact.  I don't see any cons at all, apart from potentially adding to the network load if one of the jumps involved can't handle jumbo frames, in which case they will be broken down to smaller frames partway.  Try to find a path mtu discovery program to see if this happens.  It's also not a case of sending a 9000 byte frame if you have to send "hello, world" to the other side.  The MTU for that packet would simply be set to a 12 byte frame from what I can tell.

Performance gain should be there, but don't expect to see a blinding increase in performance.  Watch weekly graphs and you may see that it's a couple of percent better or so, but I doubt much more than that.  Let us know

My books on this are getting old though.  No mention of jumbo frames in Stevens and the hardware involved is 10Mb.  The actual data link headers shouldn't have changed much, but since reliability and signal has improved since, so the frame sizes can increase.

2 Intern

 • 

326 Posts

February 26th, 2012 17:00

hi whitbs

Thank you very much for thorough ideas and explanation...we are not going down this path as yet since it's not guaranteed and proven and takes a lot of trial and error...all your points were discussed too...hence this goes to back burner...thanks again for your time ...of course points for you ;-)

No Events found!

Top