A 9000 byte MTU raises throughput on a NAS link only when every hop agrees. Set the adapter, set the IP interface, prove it with a fragmented-ping test and know how to get back to 1500.
Two settings must match: the adapter's **Jumbo Packet** property and the interface **NlMtuBytes**. Test the path with **ping -f -l 8972** before and after, and roll back to 1500 if any hop refuses.
**Get-NetIPInterface** shows the effective MTU per interface, and **netsh** shows the stored value. Write both down, because a rollback needs the original number.
Get-NetIPInterface -AddressFamily IPv4 | Select-Object InterfaceAlias,NlMtu,ConnectionState
netsh interface ipv4 show subinterfaces
Get-NetAdapter | Select-Object Name,InterfaceDescription,LinkSpeedA ping with **-f** (do not fragment) and **-l 8972** asks the path for a 9000 byte frame including headers. A reply of Packet needs to be fragmented means some hop still runs 1500.
ping -f -l 8972 192.168.1.50
ping -f -l 1472 192.168.1.50
:: 1472 is the largest payload for a 1500 byte MTU, 8972 the largest for 9000The **Jumbo Packet** advanced property controls the hardware, and its display values differ per driver. List them first, then set the matching one, usually 9014 bytes.
Get-NetAdapterAdvancedProperty -Name 'Ethernet' -DisplayName 'Jumbo*' | Select-Object DisplayName,DisplayValue,RegistryKeyword
Set-NetAdapterAdvancedProperty -Name 'Ethernet' -DisplayName 'Jumbo Packet' -DisplayValue '9014 Bytes'
Get-NetAdapterAdvancedProperty -Name 'Ethernet' -DisplayName 'Jumbo*' | Select-Object DisplayValueWindows keeps a separate MTU per IP interface. Setting only the adapter leaves the stack at 1500 and the large frames never leave the host.
netsh interface ipv4 set subinterface "Ethernet" mtu=9000 store=persistent
Get-NetIPInterface -InterfaceAlias 'Ethernet' -AddressFamily IPv4 | Select-Object NlMtu
ping -f -l 8972 192.168.1.50Pings prove configuration, not speed. Copy a large file with **robocopy** and compare the reported bytes per second against the 1500 byte baseline.
robocopy \\192.168.1.50\share D:\test big-file.iso /J /NP /NFL /NDL
Get-NetAdapterStatistics -Name 'Ethernet' | Select-Object ReceivedBytes,OutSentBytes
Get-NetAdapter -Name 'Ethernet' | Select-Object LinkSpeedOne device that does not support jumbo frames is enough to keep the whole link slow. Return the adapter property to Disabled and the interface to 1500 in the same order you set them.
Set-NetAdapterAdvancedProperty -Name 'Ethernet' -DisplayName 'Jumbo Packet' -DisplayValue 'Disabled'
netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent
ping -f -l 1472 192.168.1.50
Get-NetIPInterface -InterfaceAlias 'Ethernet' -AddressFamily IPv4 | Select-Object NlMtuOne hop in the path still runs 1500 bytes and drops the larger frames silently. Test each switch port and the NAS, then set jumbo frames everywhere or nowhere.
The driver does not expose it, or the adapter is a virtual one. Update the vendor driver; virtual switches inherit the host setting and cannot exceed it.
The WAN side stays at 1500 while the LAN side now sends 9000. Keep jumbo frames on the storage link only, or make sure path MTU discovery is not blocked by a firewall.
The tunnel adds its own header and the effective MTU shrinks. Lower the tunnel interface MTU or leave the physical adapter at 1500 while the VPN is in use.
Typically 5 to 15 percent on large sequential transfers, because fewer packets mean less per-packet overhead. Small files and many concurrent streams gain nothing.
No. 4088 and 9014 are common, and some switches support 9216. All devices must use the same frame size; the largest common value wins.
No. Those flows use small packets, and a larger MTU on a shared link can hurt latency. Apply it to the storage path only.
Set the Jumbo Packet property back to Disabled and run netsh interface ipv4 set subinterface "Ethernet" mtu=1500 store=persistent. Confirm with ping -f -l 1472 that the path is back to standard frames.
Free · no account needed · tracks your progress