A Guide to Windows NIC Advanced Settings - RSS/LSO/EEE/Wake on LAN

The [Advanced] tab of a Windows NIC is packed with unfamiliar words. Jumbo Packet, Large Send Offload, Interrupt Moderation, Receive Side Scaling, Flow Control, Energy Efficient Ethernet. Looking at the names alone makes you want to enable everything — but in reality the right answer depends on what you want to prioritize.

• Do you want to raise throughput for bulk transfers?
• Do you want to squeeze latency for small packets?
• Do you want to lower CPU usage?
• Do you want sleep resume and Wake on LAN to be stable?
• Do you want to isolate compatibility issues with drivers or switches?

Leave that vague and go “just turn everything On,” “just set Jumbo 9014,” “it’s slow, so pin it to 1Gbps Full” — and you will have an accident, quite routinely.

This article covers the practical way to think when touching NIC advanced settings, targeting mainly wired Ethernet adapters on Windows 10 / 11 / Windows Server. We lay out what each setting means, what tends to happen when you raise / lower / enable / disable it, and when each is worth touching, so you can survey it all at once.

Note that NIC display names and selectable values vary considerably by vendor and driver. Jumbo Packet may be Jumbo Frames, Receive Buffers may be Receive Descriptors, Priority & VLAN may be Packet Priority & VLAN. In this article, settings with closely related meanings are treated together.

1. The Conclusion First

First, the conclusions that rarely miss in practice.

• Speed & Duplex stays on Auto by default. When a link drops to 100Mbps, jumping straight to a pinned 1.0 Gbps Full Duplex is the last resort, not the first.
• Checksum Offload / RSS / LSO / RSC stay enabled or at defaults as a rule. Turning them all off carelessly tends to waste CPU.
• Use Jumbo Packet only when it lines up end-to-end. Set just the NIC to 9014 while the path in between stays at 1500, and you’ve dug a trap.
• Interrupt Moderation is a tug-of-war between throughput and latency. Higher settings relieve the CPU but increase latency.
• Flow Control can help reduce drops, but it can also spread congestion.
• EEE / Green Ethernet / Selective Suspend are power-saving settings, not speed settings.
• VMQ / SR-IOV are for Hyper-V hosts — not magic that speeds up an ordinary desktop PC.
• Wake on Pattern Match easily causes unintended wakes, so if all you want is Wake on LAN, leaning on Magic Packet is safer.
• Old items like TCP Chimney Offload should not be touched today.

In short, the NIC advanced settings are not “a place to enable everything that sounds powerful.” They are a place where you decide which of throughput, latency, CPU, power consumption, and compatibility you are going after, then touch one item at a time.

2. Where to Find the Settings

2.1 In the GUI

Via Network Connections

1. Run ncpa.cpl
2. Right-click the target adapter
3. Properties → Configure
4. Advanced tab

Via Device Manager

1. Device Manager
2. Network adapters
3. Right-click the target NIC → Properties
4. Advanced tab

The items lined up here are the stars of this article. That said, the settings on the Power Management tab also matter a great deal in practice, and we cover them later.

2.2 In PowerShell

PowerShell makes it easy to list current values and take a backup before changing anything.

Get-NetAdapter

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword, RegistryValue -Auto

On some NICs, RegistryKeyword uses standardized names and appears as *RSS, *VMQ, *SRIOV, *EEE, and so on. However, DisplayName and DisplayValue are driver-dependent. When writing change scripts, it is safer to enumerate the list on the actual machine first.

3. Ground Rules Before Touching Anything

Skip these before touching NIC settings and you will almost certainly end up in a swamp.

3.1 First decide “what you want to improve”

The same complaint, “the network is slow,” can mean entirely different things.

• Large file copies are slow → throughput, RSS, RSC, LSO, Jumbo, buffers
• Small request/response feels sluggish → Interrupt Moderation, RSC, EEE, queue depth
• CPU is high → offloads, RSS, RSC, interrupts
• Things go wrong after sleep resume → Selective Suspend, Power Management, WoL
• Occasional disconnects / drops to 100Mbps → cable, peer device, Speed & Duplex, EEE, driver

Touch the same settings for different goals and you’ll make things worse, not better.

3.2 Suspect the physical layer and the peer device first

There are plenty of problems NIC settings cannot fix.

• Bad cables
• Switch / router / dock compatibility
• Old firmware
• Underpowered USB NICs
• Errors on the port side
• Packet loss and retransmissions

In particular, for drops to 100Mbps, link flapping, and only bulk transfers breaking, looking at the physical layer and the peer first is faster than looking at settings.

3.3 Change one item at a time

Change Jumbo, LSO, RSC, RSS, and EEE all at once, and you’ll never know which one mattered. Write down the settings before changing, change one item at a time, and measure the difference. That’s the basic discipline.

3.4 Decide what to measure

At minimum, you want to watch these:

• Link speed (1G / 2.5G / 10G, etc.)
• Throughput
• Latency
• CPU usage
• NIC statistics (drops / errors / buffer shortage)
• Stability of sleep resume

Setting changes are far stronger when judged by numbers, not just feel.

4. The Main Settings in One Table

First, a table that shows the role of each setting at a glance.

5. Link and Frame-Size Settings

5.1 Speed & Duplex

This setting governs negotiation of link speed and full / half duplex. Display names include Speed & Duplex, Link Speed, and Link Speed & Duplex.

What it does

In Ethernet, the NIC and the peer device decide what speed and duplex to use.

You will often see options like:

• Auto Negotiation
• 100 Mbps Full Duplex
• 1.0 Gbps Full Duplex
• 2.5 Gbps Full Duplex
• 10 Gbps Full Duplex

What changes when you change it

Setting it to Auto

• Between modern devices, this is fundamentally the most stable
• At 1000BASE-T and above, Auto is often the assumed mode
• It also aligns well with EEE and master/slave negotiation

Pinning it manually

• It can fix compatibility with old switches or peers that are themselves hard-pinned
• However, a state like one side pinned / one side Auto is a recipe for accidents
• A duplex mismatch causes slowdowns, retransmissions, and bizarre delays

Practical baseline

Normally, leave it on Auto. “It won’t reach 1Gbps, so pin it to 1Gbps Full” looks decisive but usually misses the real cause.

5.2 Jumbo Packet / Jumbo Frames

This is the setting for using Ethernet frames larger than standard. Display names include Jumbo Packet, Jumbo Frames, and Jumbo Packet Size.

What it does

Ordinary Ethernet usually operates with an assumed MTU of 1500. Enabling Jumbo Frames lets you use large frames of around 9000 bytes.

But this area is full of naming traps.

• Drivers may display the frame size, like 9014 Bytes
• The OS and tools may use the L3 view, like MTU 9000
• Switches may count including CRC or VLAN tags

Compare the raw numbers side by side and you will get caught, quite routinely.

What changes when you change it

Raising / enabling it

• Fewer packets when sending large data
• Fewer header-processing passes
• CPU usage tends to drop
• On the other hand, each packet occupies the wire longer
• If anything along the path doesn’t support it, it causes drops or fragmentation

Restoring standard / disabling it

• Highest compatibility
• More packets
• CPU / header overhead rises on bulk transfers

Practical baseline

Jumbo only means something when it lines up end-to-end:

• your NIC
• the peer’s NIC
• the switches in between
• the overhead of any VLANs or virtual switches in the path

If any one of those stays at 1500, you get no benefit — and likely new problems instead.

5.3 Gigabit Master / Slave Mode

On 1000BASE-T, this setting concerns which side leads the clock as master and which follows as slave. On an ordinary PC you essentially never touch it.

Baseline

• Auto by default
• Evaluate it only for link-quality problems with specific old peer equipment
• Unless the vendor says otherwise, do not treat it as a performance-tuning knob

5.4 Wait for Link and other link-state settings

Settings like Wait for Link concern whether the driver waits for auto-negotiation to succeed before reporting link state. Log Link State Event is a diagnostic that records link up/down in the event log.

Baseline

• Ordinary PCs can stay at defaults
• They matter more for boot-time appearances and failover diagnostics than raw performance
• Not items to touch first

6. Settings That Affect CPU Load, Throughput, and Latency

This is the band that looks most “promising.” It often does help — but the direction of help splits cleanly.

6.1 Checksum Offload

Pushes IP / TCP / UDP checksum computation onto the NIC.

Baseline

• Enabled as a rule
• Keep it if you want lower CPU
• Checksum errors seen in captures are usually an artifact of offloading
• Temporarily disabling it for compatibility isolation is fine

6.2 Large Send Offload (LSO) / TSO / Offload TCP Segmentation

The NIC splits large TCP send data into small frames.

What it helps

• Send-heavy throughput
• Reduced CPU usage
• Larger sustained sends

Baseline

• Normally enabled
• If a specific app or driver compatibility is suspect, temporarily disable it and compare

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

Coalesces multiple TCP segments on the receive side.

What it helps

• Receive-side throughput
• Reduced CPU usage

Caveats

• It can be a disadvantage for low latency or per-packet observation
• It slightly changes how captures and timing observations should be interpreted

Baseline

• Enable if you want receive throughput
• Evaluate it if you care about latency of small request/response traffic

6.4 Newer UDP offloads (USO / URO)

On recent NICs and OS versions, newer offloads may also appear for UDP send/receive.

Baseline

• Even if present, don’t stray from defaults at first
• Measure only when the driver is sufficiently new and the target workload is clear
• Don’t force it during troubleshooting

6.5 Receive Side Scaling (RSS)

Spreads receive processing across multiple CPUs. On multi-core machines this matters a great deal.

Baseline

• Enabled by default on multi-core
• Check it first whenever a single CPU is pegged
• It also takes center stage in front of Hyper-V and high-throughput setups

6.6 RSS Queues / RSS Processors / RSS Profile

These determine the degree of RSS parallelism.

Baseline

• Start from defaults
• Increase only after CPU usage or queue skew is visible
• Cranking it to maximum blindly can increase interrupt and DPC load

6.7 Interrupt Moderation / Interrupt Moderation Rate

Throttles interrupt frequency, trading CPU load against latency.

Tendencies

• Higher / Adaptive → CPU relief, but latency tends to rise
• Lower / Off → Lower latency, but CPU / DPC load tends to rise

Baseline

• Start from default / Adaptive
• Evaluate Low / Off if small-packet jitter bothers you
• For bulk transfers, the defaults are usually the saner choice

6.8 Receive Buffers / Receive Descriptors and Transmit Buffers / Transmit Descriptors

These change the depth of the rings / buffers.

What they help

• Burst tolerance
• Sustained throughput
• Drop avoidance

Side effects

• More memory consumption
• Deeper queues can add queuing delay

Baseline

• Increase only when drops or buffer shortage are visible
• Avoid “maximum, just because”

6.9 Flow Control

Concerns sending and receiving 802.3x pause frames.

Baseline

• A candidate if you want fewer drops
• But pause frames can spread congestion elsewhere
• Treat it cautiously in low-latency systems
• Consider it together with the overall network design

7. VLAN, QoS, and Virtualization Settings

7.1 Priority & VLAN / Packet Priority & VLAN / NDIS QoS

The band that handles 802.1Q VLANs and 802.1p priority.

Baseline

• Only think about it when you genuinely use VLAN / QoS
• In a simple access-port environment, defaults are fine
• Configurations that tag frames implicitly make isolation harder — beware

7.2 VMQ / VMMQ / SR-IOV

These settings only become meaningful on Hyper-V hosts and virtualization platforms.

Baseline

• Not part of ordinary desktop tuning
• On a Hyper-V host, evaluate them together with the vSwitch configuration, queue assignment, and guest-side settings
• Looking at only one side rarely yields the right answer

7.3 RDMA / DCB / PFC are another world

This area — including SMB Direct and lossless Ethernet — is genuinely a different world.

Baseline

• Keep it separate from ordinary 1GbE / 2.5GbE desktop tuning
• Check vendor documentation together with the switch-side design

8. Power Saving, Sleep, and Wake on LAN Settings

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

Reduces power consumption during link idle, for energy saving.

How to see it

• Not a speed setting
• It does affect power consumption
• Depending on the peer device and cabling, it becomes an isolation candidate for unstable links or 100Mbps downshifts

Baseline

• For general use, defaults are fine
• For unstable links, 100Mbps downshifts, or latency-critical use, it is a first isolation candidate

8.2 Selective Suspend / Device Sleep / standby link control

Plainly put: how deeply the NIC is allowed to sleep when idle or during system sleep.

Baseline

• On laptops, start from defaults
• If there are resume problems, suspect this first
• For equipment-control PCs and 24/7 operation, disabling it outright is often the clearer choice

8.3 Wake on Magic Packet / Wake on Pattern Match

These wake a sleeping PC over the network.

Baseline

• If you need Wake on LAN, enable Magic Packet
• If not, disable
• Pattern Match only when the need is explicit

Turning it on only at the NIC and not waking is entirely normal. Check the BIOS / UEFI side and the Power Management tab as a set.

8.4 ARP Offload / NS Offload

The NIC answers minimal traffic on the system’s behalf even during sleep.

Baseline

• Normally enabled / defaults is fine
• It mostly gets touched temporarily when isolating sleep-related compatibility issues

8.5 The Power Management tab

Separate from the Advanced tab, the NIC’s properties have a Power Management tab. It is quietly important too.

The three you see most:

• Allow the computer to turn off this device to save power
• Allow this device to wake the computer
• Only allow a magic packet to wake the computer

Baseline

• For resume failures, suspect Allow the computer to turn off this device... first
• To avoid spurious wakes, enable Only allow a magic packet...
• If Wake on LAN itself isn’t needed, all the wake settings can stay disabled

9. Other Settings You See Often but Rarely Touch

9.1 Network Address / Locally Administered Address

A setting that manually overrides the MAC address.

Baseline

• Don’t touch it normally
• Not a performance setting
• Use only in lab environments or for special requirements

9.2 Adaptive Inter-Frame Spacing

A genuine old-timer. On modern switched full-duplex Ethernet it plays no leading role.

Baseline

• On a modern, ordinary LAN, leave at defaults
• Touch only when old equipment or special environments come with vendor instructions

9.3 Header Data Split

Mainly server-oriented: helps CPU processing by handling packet headers and payloads separately.

Baseline

• For servers / specific workloads
• On general clients, leave at defaults

9.4 Low Latency Interrupts

Some vendors expose an item like Low Latency Interrupts.

Baseline

• Use it only when measurement proves it wins
• Not a band to switch On by vibe

9.5 Old items like TCP Chimney Offload / IPsec Task Offload

You may see these on older NICs and drivers.

Baseline

• Don’t touch, don’t use is the correct answer today
• Don’t be pulled along by compatibility lore or old documents

10. Rough Guidance by Goal

10.1 Ordinary desktop / laptop

• Speed & Duplex: Auto
• MTU / Jumbo: 1500 / disabled
• Checksum Offload: enabled
• LSO: enabled
• RSC: enabled
• RSS: enabled
• Interrupt Moderation: default / Adaptive
• Buffers: defaults
• Flow Control: defaults
• EEE / Green Ethernet: defaults
• Selective Suspend: defaults
• Wake on LAN: only when needed

In other words, don’t stray from the defaults is the baseline.

10.2 NAS / backup / bulk copies

• Speed & Duplex: Auto
• Jumbo: evaluate if a dedicated path can be matched end-to-end
• Checksum Offload: enabled
• LSO: enabled
• RSC: enabled
• RSS: enabled
• RSS queues: increase slightly if needed
• Receive / Transmit Buffers: increase slightly if drops appear
• Interrupt Moderation: default / somewhat higher
• EEE: evaluate disabling if stability comes first

For large transfers, fewer packets, less CPU, and avoiding queue shortage are what tend to pay off.

10.3 Industrial cameras / equipment control / latency-critical

• Speed & Duplex: Auto by default; pin to match the peer if necessary
• Jumbo: evaluate if camera / NIC / switch all line up
• Checksum Offload: enabled first
• LSO: temporarily evaluate disabling if send-side compatibility is suspect
• RSC: a disable candidate when latency or observation comes first
• Interrupt Moderation: evaluate Low / Off
• Buffers: don’t over-provision
• Flow Control: evaluate the side effects of pause frames
• EEE / Green Ethernet: a disable candidate
• Selective Suspend / power management: a disable candidate

Throughput-optimized settings are not automatically favorable for low latency.

10.4 Hyper-V hosts

• VMQ / VMMQ / SR-IOV: evaluate per configuration
• RSS: important for host-side traffic
• RSC: constrained by the vSwitch configuration
• QoS / VLAN: align with the vSwitch design
• Flow Control / PFC: consider together with the storage / RDMA design

This is not desktop tuning — it is virtualization platform design.

10.5 Temporary settings for troubleshooting

When isolating a defect, returning to a simple world is powerful.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: disabled
• EEE: disabled
• LSO: temporarily disabled
• RSC: temporarily disabled
• Interrupt Moderation: default or lower
• Wake / power save: disabled if not needed
• Pre-change settings: always saved

In isolation work, simplifying behavior beats optimizing performance.

11. First Places to Look, by Symptom

11.1 Supposed to be 1Gbps / 2.5Gbps, but it’s 100Mbps

The order to check is roughly this.

1. Cable
2. Dock / USB NIC / adapter dongles
3. The switch-side port
4. Driver update
5. EEE / Green Ethernet
6. Return Speed & Duplex to Auto
7. If all else fails, try a pinned setting matched to the peer

Manual pinning comes last, not first.

11.2 Bulk transfers are slow, but ping is normal

What you want to look at:

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frames (if the path is dedicated)
• Drops / errors in the NIC statistics

This is a throughput-class problem, so Jumbo, queues, and offloads tend to be what helps.

11.3 Small request/response latency is high, or jitter bothers you

The five things to check:

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Whether the buffers have been over-provisioned

In this band, batching-style optimizations can actually increase perceived latency.

11.4 The NIC disappears after sleep resume / no connectivity for a few seconds

Centering on power management, the five things to look at:

• Selective Suspend
• Device Sleep / standby-related settings
• Allow the computer to turn off this device... on the Power Management tab
• Dock / USB NIC firmware
• The combination of wake settings

Resume trouble is more often about power management than about the NIC itself.

11.5 Packet captures show masses of checksum errors

Before panicking and declaring “the line is broken,” check these.

• Is Checksum Offload enabled?
• Is LSO enabled?
• Is the capture taken before transmission, or on the wire?
• Does it look the same from another host or a mirror port?

Checksum errors in a local capture are, truly often, just how offloading looks.

11.6 Only Hyper-V VMs are slow / CPU is skewed

What to look at goes beyond desktop-style RSS.

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• The division of labor between host-side RSS and VM-side queues

In virtualization, drawing a picture of who is actually processing the packets makes things much easier to sort out.

12. Practical Notes for Checking and Changing via PowerShell

12.1 Save the current state first

A backup before changing matters.

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Select-Object Name, DisplayName, DisplayValue, RegistryKeyword, RegistryValue |
  Export-Csv .\nic-advanced-backup.csv -NoTypeInformation -Encoding UTF8

12.2 List the settings

Get-NetAdapterAdvancedProperty -Name "Ethernet" |
  Sort-Object DisplayName |
  Format-Table DisplayName, DisplayValue, RegistryKeyword -Auto

12.3 Check RSS / RSC / statistics

Get-NetAdapterRss -Name "Ethernet"
Get-NetAdapterRsc -Name "Ethernet"
Get-NetAdapterStatistics -Name "Ethernet"

12.4 Change examples

Actual display names differ per NIC, so list them first, then change.

# Example: change Jumbo Packet (values differ per NIC)
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "Jumbo Packet" `
  -DisplayValue "9014 Bytes"

# Example: set the number of RSS receive queues
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 4

12.5 Verifying Jumbo connectivity

# Equivalent to standard MTU 1500
ping <peer IP> -f -l 1472

# Equivalent to MTU 9000
ping <peer IP> -f -l 8972

1472 and 8972 are the payload sizes after subtracting the IP / ICMP headers. The driver UI’s 9014 Bytes and these ping numbers do not match each other.

12.6 Practical notes

• Some settings require disabling / re-enabling the adapter or a reboot
• DisplayName may be localized
• Even within the same vendor, item names can change with the driver version
• If automating with PowerShell, it is safer to enumerate the values on the actual machine first, then write

13. Summary

Judged by item names alone, every Windows NIC advanced setting looks “powerful.” In reality, this is a world where the right answer changes depending on whether you are going after throughput, latency, CPU, power, or compatibility.

Summing up the key points of this article:

• Speed & Duplex stays on Auto by default
• Jumbo only when it lines up end-to-end
• Checksum / RSS / LSO / RSC: the defaults are strong, as a rule
• Interrupt Moderation is a throughput-versus-latency trade-off
• Buffers: only as much as needed
• EEE / Selective Suspend / Wake settings are about power and resume
• VMQ / SR-IOV are a Hyper-V matter
• Don’t touch the old offload items

And the three things that matter most:

1. Decide what you want to improve
2. Change one item at a time
3. Compare before and after with numbers

NIC settings are not a magic go-faster switch. But when the goal is right, they pay off considerably. When the goal is off, they backfire just as readily.

14. References

The following are the official and vendor materials this article was built on. Windows and NIC drivers vary a lot in terminology, so in the end it is safest to verify against the driver name and version of your own NIC.

• Microsoft Learn: NIC advanced properties
• Microsoft Learn: Network Adapter Performance Tuning in Windows Server
• Microsoft Learn: Hardware Only (HO) features and technologies
• Microsoft Learn: Overview of Single Root I/O Virtualization (SR-IOV)
• Microsoft Learn: Standardized INF Keywords for NDIS QoS
• Microsoft Learn: Standardized INF Keywords for Power Management
• Microsoft Learn: Setting RSS parameters
• Microsoft Learn: Overview of receive segment coalescing
• Microsoft Learn: How to optimize network adapter power management settings
• Microsoft Learn: Deprecated networking features in Windows Server
• Intel Support: Advanced Settings for Intel Ethernet Adapters
• Intel Support: for pinned speeds, Jumbo, Interrupt Moderation, EEE, WoL and the like, it is safest to check the support articles for your specific NIC model

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.