What, if any, are the performance implications of running a larger interface MTU than required on an interface.
I am looking to support jumbo frames within an MPLS network and am trying to determine if it's worthwhile to fine tune interface MTUs to the match the immediate requirement, or simply use the max MTU on all ports to simplify changing to larger tunnel MTUs in future as required.
Large MTU - Performance Implications
-
sirhc - Employee
- Posts: 7419
- Joined: Tue Apr 08, 2014 3:48 pm
- Location: Lancaster, PA
- Has thanked: 1609 times
- Been thanked: 1325 times
Re: Large MTU - Performance Implications
There are tons of white papers on the net discussing this, pros and cons and so forth.
Running larger than standard MTU as the internet as a whole runs standard MTUs. On wireless networks the larger MTUs will really only effect PTP destinations within your network because when the packet reaches your edge to ventures out onto the world wide web the packet will need to be broken down into smaller packets.
Also on a wireless networks wireless errors are pretty common which means that when packet retries occur you lose more data and the rety is larger. Also this larger MTU "can" effect time slicing on PTMP links.
For my WISP I found running the standard MTU works best for me but there is a wealth of information on this on the web and you will find different opinions on both sides of the issue. The opposite of what you see on big tech social media platforms where any decent or difference of opinion will land you in FB or Twitter jail, have to stay in lock step and group think.
Personally I value debate and opposing viewpoints because usually the solution or true "facts" lies somewhere in the middle but this can never happen if only one option is allowed. God forbid if someday big tech decides either Ford or Chevy is better then that debate will be canceled. /END RANT
Running larger than standard MTU as the internet as a whole runs standard MTUs. On wireless networks the larger MTUs will really only effect PTP destinations within your network because when the packet reaches your edge to ventures out onto the world wide web the packet will need to be broken down into smaller packets.
Also on a wireless networks wireless errors are pretty common which means that when packet retries occur you lose more data and the rety is larger. Also this larger MTU "can" effect time slicing on PTMP links.
For my WISP I found running the standard MTU works best for me but there is a wealth of information on this on the web and you will find different opinions on both sides of the issue. The opposite of what you see on big tech social media platforms where any decent or difference of opinion will land you in FB or Twitter jail, have to stay in lock step and group think.
Personally I value debate and opposing viewpoints because usually the solution or true "facts" lies somewhere in the middle but this can never happen if only one option is allowed. God forbid if someday big tech decides either Ford or Chevy is better then that debate will be canceled. /END RANT
Support is handled on the Forums not in Emails and PMs.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
-
quantumx - Member
- Posts: 24
- Joined: Wed Dec 03, 2014 1:46 pm
- Location: Ontario, CANADA
- Has thanked: 4 times
- Been thanked: 3 times
Re: Large MTU - Performance Implications
Thanks for the response Chris.
I am aware of the debate. What I am asking - does enabling a larger MTU on Netonix kit have any negative consequences?
ie. reduced buffering capacity, increased latency, reduced PPS handling
If this is unknown, I can test.
Thanks.
I am aware of the debate. What I am asking - does enabling a larger MTU on Netonix kit have any negative consequences?
ie. reduced buffering capacity, increased latency, reduced PPS handling
If this is unknown, I can test.
Thanks.
-
Dave - Employee
- Posts: 726
- Joined: Tue Apr 08, 2014 6:28 pm
- Has thanked: 1 time
- Been thanked: 158 times
Re: Large MTU - Performance Implications
I would call it somewhat of an unknown, I know some people have simply set MTU size larger and had no issues..best to test for your setup.
-
sirhc - Employee
- Posts: 7419
- Joined: Tue Apr 08, 2014 3:48 pm
- Location: Lancaster, PA
- Has thanked: 1609 times
- Been thanked: 1325 times
Re: Large MTU - Performance Implications
quantumx wrote:Thanks for the response Chris.
I am aware of the debate. What I am asking - does enabling a larger MTU on Netonix kit have any negative consequences?
ie. reduced buffering capacity, increased latency, reduced PPS handling
If this is unknown, I can test.
Thanks.
So the switch core is rated at line speed for all ports all maxed at the same time. Meaning on a WS-6 with 6 1G ports the switching core capacity is 6 Gbps regardless of MTU or packet size so changing the MTU should have no impact on the performance of the switch as far as capacity of data. This is not a software switch which all packets touch a single CPU or say a software router which again all packets touch the CPU. Data through our switch does not touch the CPU running UI/CLI which is used primarily to configure the switch CORE. We can route packets to the CPU running the UI/CLI but that would be stupid as that CPU is small and at best could handle less than 60 Mbps, think a small home office router all packets coming from the WAN port to the LAN port(s) has to be processed by that small CPU. Now small routers with 4 LAN ports is usually a CPU to run the UI/CLU and all routed packets touch that CPU but the 4 port switch is usually a very cheap non managed switch chip which handles switching between those 4 ports at line speed but from WAN to the 4 LAN ports has a max routing capacity. Back in the days of say the old Linksys wireless APs running Open WRT was about 60 Mbps +/- between WAN and LAN but between LAN ports was 100 Mbps or 1Gbps depending on what the LAN port speeds were.
reduced buffering capacity
Well obviously the amount of buffer space is limited and based how many bites the buffer can handle so the larger the packets the less packets that can be buffered but the same amount of date taking into account for packet headers and such as headers are data and count towards the buffer capacity. Most switches have so much memory and "usually" the buffer memory is dynamically assigned to ports based on their need at that moment in time.
increased latency
Well obvious this could affect this to some degree based on packet retries and or if it is a clean environment with no errors (good luck in wireless) . But this is not a clean cut answer and would be debated based on network architecture. Keep in mind for VOIP, gaming, telemetry most packets would be smaller than JUMBO packets.
reduced PPS handling
Well obviously the ports are rated based on actual data through put. Meaning the larger the packets if maxing out a 1G port the pps would be less.
Can it cause issues
Well that all depends on what device it is talking to on the other side and how it is setup as well as all the devices between source and destination.
This is not a simple clean cut binary answer.
Support is handled on the Forums not in Emails and PMs.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
Before you ask a question use the Search function to see it has been answered before.
To do an Advanced Search click the magnifying glass in the Search Box.
To upload pictures click the Upload attachment link below the BLUE SUBMIT BUTTON.
5 posts
Page 1 of 1
Who is online
Users browsing this forum: Bing [Bot] and 45 guests