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 out of 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 a compatibility problem with a driver or a switch?

Leave that vague and go with “just turn everything On,” “just set Jumbo 9014,” or “it’s slow, so pin it to 1Gbps Full,” and you will break something, quite routinely.

flowchart TB
    accTitle: Touching settings without a clear goal breaks things
    accDescr: A diagram showing that turning everything On, enabling Jumbo, or pinning the speed while it is still vague what you want to prioritize tends to break things, and that deciding the priority first changes which setting is the right one.
    vague1["Unclear what to prioritize"] --> hasty1["Everything On, Jumbo, pinned speed"]
    hasty1 --> acc1["Something breaks, quite routinely"]
    clear1["Decide what to prioritize"] -->|"that changes the right answer"| pick3["The settings worth touching narrow down"]

Figure 1: Touching the impressive-looking settings without a goal breaks things; deciding the goal narrows down where to touch.

This article covers the practical way to think when touching NIC advanced settings, targeting mainly wired Ethernet adapters on Windows 10 / 11 / Windows Server. It lays out what each setting means, what tends to happen when you raise it, lower it, enable it, or disable it, and when each one is worth touching, so you can survey the whole area 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, and Priority & VLAN may be Packet Priority & VLAN. In this article, settings with closely related meanings are treated together.

How to Use This Article

There are 14 chapters and it runs long, so here is a map first. You do not need to read all of it.

The most common path is probably “start from the symptom, go to Chapter 11, then the chapter for that setting, then Chapter 10 to put things back.”

flowchart TB
    accTitle: The most common reading path
    accDescr: A diagram showing the reading path of starting from a symptom, checking the symptom-based starting points in Chapter 11, confirming the meaning in the relevant setting chapter, and putting things back with the goal-based guidance in Chapter 10.
    sym1["Start from a symptom"] --> ch11["Chapter 11 (symptom-based starting points)"]
    ch11 --> chd1["Chapter for that setting (Chapters 5-9)"]
    chd1 --> ch10["Chapter 10 (put things back with goal-based guidance)"]

Figure 2: Enter from a symptom into Chapter 11, pass through the chapter for that setting, and put things back with the guidance in Chapter 10.

A Mini Glossary of Abbreviations

So you can read this side by side with the settings dialog, here are the abbreviations that appear in this article.

1. The Conclusion First

To start, here are the conclusions that are hard to get wrong 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 move, not the first.
• Checksum Offload / RSS / LSO / RSC should, as a rule, be enabled or left at their defaults. Turning them all off carelessly tends to waste CPU.
• Use Jumbo Packet only when it lines up end-to-end. Setting only your NIC to 9014 while a hop along the path stays at 1500 is a trap.
• Interrupt Moderation is a tug-of-war between throughput and latency. Raise it and the CPU gets an easier time, but latency grows.
• Flow Control can work in the direction of reducing drops, but it can also spread congestion.
• EEE / Green Ethernet / Selective Suspend are power-saving settings, not settings that make things faster.
• VMQ / SR-IOV are for Hyper-V hosts, not magic that speeds up an ordinary desktop PC.
• Wake on Pattern Match easily becomes a source of unintended wakes, so if all you want is Wake on LAN, leaning on Magic Packet is safer.
• Old items such as TCP Chimney Offload are better left alone today.

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

flowchart TB
    accTitle: What the advanced settings tab is for
    accDescr: A diagram showing that NIC advanced settings are not a place to enable everything that sounds powerful, but a place to decide which of throughput, latency, CPU, power consumption, and compatibility you are going after and then touch one item at a time.
    allon1["Enable everything that sounds powerful"] -.->|"not what this place is for"| tab1["NIC advanced settings"]
    dec1["Decide which axis you are going after"] --> one2["Touch one item at a time"]
    one2 --> tab1

Figure 3: Use the advanced settings tab as a place to decide the axis you want first, then touch one item at a time.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (26 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Where to Look at the Settings

2.1 Looking Through the GUI

Entering from Network Connections

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

Entering from Device Manager

1. Open Device Manager
2. Go to Network adapters
3. Right-click the target NIC and choose Properties
4. The Advanced tab

The items listed there are the subject of this article. That said, the settings on the Power Management tab also matter a great deal in practice, so they are covered later on.

2.2 Looking Through PowerShell

PowerShell makes it easier to list the current values and to back them up before making changes.

Get-NetAdapter

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

On some NICs the RegistryKeyword uses a standardized name, so you see things like *RSS, *VMQ, *SRIOV, and *EEE. However, DisplayName and DisplayValue are driver dependent. When writing a script that changes settings, it is safer to list them on the actual device first.

flowchart TB
    accTitle: The order to follow when checking with PowerShell
    accDescr: A diagram showing the safe order of listing the properties on the actual device first, confirming that display names are driver dependent, and only then writing a script that changes settings.
    lst1["List the properties on the actual device"] --> dep1["Confirm display names are driver dependent"]
    dep1 --> scr1["Only then write the change script"]
    scr1 -.-> bk1["Also back up the settings before changing"]

Figure 4: Because display names are driver dependent, list the properties on the actual device before writing the script.

3. Ground Rules Before Touching Anything

Before touching NIC settings, getting these wrong is usually what turns the work into a slog.

3.1 First Decide What You Want to Improve

The same phrase “the network is slow” can mean completely different things.

• Large file copies are slow -> throughput, RSS, RSC, LSO, Jumbo, buffers
• Small request/response traffic feels sluggish -> Interrupt Moderation, RSC, EEE, queue depth
• CPU usage is high -> offloads, RSS, RSC, interrupts
• Something is wrong after sleep resume -> Selective Suspend, Power Management, WoL
• The link occasionally drops or falls to 100Mbps -> the cable, the peer device, Speed & Duplex, EEE, the driver

Touching the same setting for a different goal makes things worse rather than better.

flowchart TB
    accTitle: Separate what slow actually means first
    accDescr: A diagram showing that the same symptom of a slow network can mean completely different things, and that unless you decide what to improve first and touch only the matching group of settings, things get worse instead of better.
    slow1["The network is slow"] --> split1["Separate what it actually means first"]
    split1 --> aim1["Touch only the settings that match the goal"]
    slow1 -.->|"touching without separating"| worse1["Worse rather than better"]

Figure 5: Unless you separate what the symptom actually is before touching anything, the same word “slow” leads you the wrong way.

3.2 Suspect the Physical Layer and the Peer Device First

Plenty of problems are not fixed by NIC settings at all.

• A bad cable
• Compatibility with a switch, router, or dock
• Old firmware
• Insufficient power for a USB NIC
• Errors on the port side
• Packet loss and retransmissions

In particular, for drops to 100Mbps, a flapping link, and only bulk transfers breaking, it is faster to look at the physical layer and the peer before the settings.

flowchart TB
    accTitle: Look at the physical layer and the peer device first
    accDescr: A diagram showing that for symptoms such as downshifts to 100Mbps, a flapping link, or only bulk transfers breaking, suspecting the physical layer including the cable and the peer device is faster than starting from NIC settings.
    symp1["Symptoms such as downshift or flapping"] --> phys1["First the cable, the peer device, the physical layer"]
    phys1 -->|"if it still remains"| nicw1["Move on to isolating NIC settings"]
    phys1 -.-> nofix1["Plenty of problems settings cannot fix"]

Figure 6: For link-related symptoms, suspecting the physical layer and the peer device is faster than starting from the settings.

3.3 Change Exactly One Item at a Time

Change Jumbo, LSO, RSC, RSS, and EEE all at once and you will not know which one did anything. The baseline is to write down the settings before the change, alter one item at a time, and measure the difference.

3.4 Decide What to Measure

At a minimum, these are worth watching.

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

Judging a settings change by numbers rather than by feel is far stronger.

flowchart TB
    accTitle: Change one item at a time and compare with numbers
    accDescr: A diagram showing the basic flow of a settings change: write down the settings before the change, alter exactly one item, measure the metrics you decided on, and compare with numbers rather than by feel.
    w1["Write down the settings before the change"] --> w2["Change exactly one item"]
    w2 --> w3["Measure the metrics you decided on"]
    w3 --> w4["Compare with numbers, not by feel"]

Figure 7: Change one item at a time and compare before and after with numbers. That is the basic pattern.

4. Overview Table of the Main Settings

First, a single table showing the role of each setting at a glance.

5. Settings Around Links and Frame Size

5.1 Speed & Duplex

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

What the Setting Does

In Ethernet, the NIC and the peer device determine which speed and which duplex mode to use.

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

Options like these are the usual set.

What Changes When You Change It

Setting it to Auto

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

Pinning it manually

• It sometimes improves compatibility with old switches, or with a peer that is itself hard-pinned
• However, a state where one side is pinned and the other is on Auto is asking for trouble
• Causing a duplex mismatch leads to reduced speed, retransmissions, and abnormal delays

The Baseline Policy in Practice

Normally, leaving it on Auto is fine. “It won’t do 1Gbps, so pin it to 1Gbps Full” looks decisive but usually misses the real issue.

flowchart TB
    accTitle: The duplex mismatch that one-sided pinning invites
    accDescr: A diagram showing that a state where one side is pinned and the other is on Auto causes duplex mismatch leading to reduced speed, retransmissions, and abnormal delays, and that Auto on both sides is fundamentally the most stable between modern devices.
    mix1["One side pinned, the other on Auto"] --> mm1["duplex mismatch"]
    mm1 --> sl2["Reduced speed, retransmissions, abnormal delays"]
    auto1["Auto on both sides"] -->|"between modern devices"| stb1["Fundamentally the most stable"]

Figure 8: Mixing a pinned side with an Auto side causes duplex mismatch, so normally leave both sides on Auto.

5.2 Jumbo Packet / Jumbo Frames

This is the setting that uses Ethernet frames larger than the standard size. Display names include Jumbo Packet, Jumbo Frames, and Jumbo Packet Size.

What the Setting Does

Ordinary Ethernet usually runs on the assumption of MTU 1500. Enabling Jumbo Frames lets you use large frames of around 9000 bytes.

There are plenty of naming traps here, though.

• The driver may show the frame size, such as 9014 Bytes
• The OS and tools may take an L3 view, such as MTU 9000
• The switch may count including CRC and VLAN tags

Comparing the numbers side by side is a very easy way to get stuck.

flowchart TB
    accTitle: Different ways of counting the Jumbo numbers
    accDescr: A diagram showing that for the same Jumbo configuration the driver may show the frame size, the OS and tools may show the MTU from an L3 view, and the switch may count including tags and CRC, so comparing the numbers side by side leads to trouble.
    drv1["Driver: shows the frame size"] --> cmp2["Looking at the same thing counted differently"]
    osv1["OS and tools: MTU from an L3 view"] --> cmp2
    sw1["Switch: includes tags and CRC"] --> cmp2
    cmp2 --> trap1["Comparing raw numbers side by side leads to trouble"]

Figure 9: The driver, the OS, and the switch count differently, so do not compare Jumbo numbers side by side.

What Changes When You Change It

Raising it or enabling it

• The packet count drops when sending large amounts of data
• Header processing happens fewer times
• CPU usage tends to fall
• On the other hand, each packet occupies the wire for longer
• If any hop along the path does not support it, that causes drops or fragmentation

Returning to standard or disabling it

• Compatibility is at its highest
• The packet count goes up
• CPU and header overhead tend to rise for bulk transfers

The Baseline Policy in Practice

Jumbo only means anything when it lines up end-to-end.

• Your own NIC
• The peer’s NIC
• The switches along the way
• The overhead of any VLAN or virtual switch in the path

If any one of these stays at 1500, you not only lose the benefit, you gain a source of trouble.

flowchart TB
    accTitle: Jumbo only means anything when it lines up end-to-end
    accDescr: A diagram showing that Jumbo Frames only mean anything when your NIC, the switches along the way, and the peer NIC line up end-to-end, and that if any one of them stays at 1500 you not only lose the benefit but gain a source of trouble.
    myn1["Your own NIC"] --> mid1["The switches along the way"]
    mid1 --> yrn1["The peer NIC"]
    yrn1 --> okj1["Only means anything when all of them line up"]
    mid1 -.->|"if any one stays at 1500"| ngj1["No benefit and a source of trouble"]

Figure 10: Jumbo assumes everyone on the path lines up; one hop left at 1500 makes it counterproductive.

5.3 Gigabit Master / Slave Mode

On 1000BASE-T, this setting governs which side leads the clock as master and which follows as slave. On an ordinary PC you will hardly ever touch it.

Baseline Policy

• Auto is the baseline
• Evaluate it only for link quality problems with specific old peer devices
• Unless a vendor tells you otherwise, do not treat it as a performance tuning knob

5.4 Wait for Link and Other Link State Settings

A setting such as Wait for Link governs whether the driver waits for auto negotiation to succeed before reporting link state. Log Link State Event is a diagnostic setting that records link up and down in the event log.

Baseline Policy

• On an ordinary PC, the default is fine
• These matter for how things look at boot and for failover diagnostics rather than for performance itself
• They are not the first items to touch

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

This is the band that looks the most “effective.” It often is effective, but the direction in which it works splits cleanly.

flowchart TB
    accTitle: The settings in this band split by direction
    accDescr: A diagram showing that the settings affecting CPU load, throughput, and latency split cleanly into a direction that batches processing to gain throughput and CPU headroom and a direction that processes finely to gain latency.
    band1["The band of settings that look effective"] --> dir1["The direction that batches processing"]
    band1 --> dir2["The direction that processes finely"]
    dir1 -.-> g1["Favors throughput and CPU"]
    dir2 -.-> g2["Favors latency"]

Figure 11: Even within the same band, settings split into throughput-leaning and latency-leaning directions.

6.1 Checksum Offload

This setting moves IP / TCP / UDP checksum calculation onto the NIC.

Baseline Policy

• Enabled as a rule
• Keep it if you want lower CPU
• Checksum errors in a capture are usually just how offload looks
• Turning it off temporarily to isolate a compatibility issue is fair game

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

This setting has the NIC split large TCP send data into individual frames.

What It Helps

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

Baseline Policy

• Normally enabled
• When a specific application or driver looks like a compatibility problem, disable it temporarily and look at the difference

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

This setting coalesces multiple TCP segments on the receive side.

What It Helps

• Receive-side throughput
• Reduced CPU usage

Points to Watch

• It can work against you for low latency and per-packet observation
• It slightly changes how you interpret captures and timing measurements

Baseline Policy

• Enable it if you want receive throughput
• Treat it as a candidate for evaluation if you care about the latency of small request/response traffic

flowchart TB
    accTitle: How RSC works and where evaluation splits
    accDescr: A diagram showing that RSC coalesces multiple received TCP segments on the NIC and helps receive throughput and CPU reduction, while it can work against you for low latency and per-packet observation and therefore becomes a candidate for evaluation.
    seg1["Multiple received TCP segments"] --> coal1["Coalesced on the NIC (RSC)"]
    coal1 --> up1["Helps receive throughput and CPU"]
    coal1 -.->|"when low latency or observation comes first"| dn1["Can work against you, so evaluate it"]

Figure 12: RSC batches receive processing, so if what you want is latency, it becomes a candidate for evaluation.

6.4 Newer UDP Offloads (USO / URO)

On recent NICs and operating systems, newer offloads can show up for UDP sends and receives as well.

Baseline Policy

• Even when they are exposed, start by not deviating from the defaults
• Measure only when the driver is new enough and the target workload is clearly defined
• Do not force changes to them during troubleshooting

6.5 Receive Side Scaling (RSS)

This setting spreads receive processing across multiple CPUs. It matters a great deal in multi-core environments.

Baseline Policy

• Enabled by default on multi-core
• Check it first when the symptom is one CPU pegged at full load
• It also tends to be the leading factor even before you get into Hyper-V or high-throughput territory

flowchart TB
    accTitle: How receive processing changes with and without RSS
    accDescr: A diagram showing that with RSS disabled receive processing concentrates on a single CPU and tends to bottleneck, while enabling it spreads the work across multiple CPUs so throughput tends to scale in multi-core environments.
    rin1["Receive traffic"] -->|"RSS disabled"| one3["Concentrates on a single CPU and bottlenecks"]
    rin1 -->|"RSS enabled"| sp2["Spread across multiple CPUs"]
    sp2 --> sc1["Tends to scale on multi-core"]

Figure 13: RSS is the mechanism that spreads receive processing across CPUs, so check it first when a single CPU is pegged.

6.6 RSS Queues / RSS Processors / RSS Profile

These items determine the degree of parallelism for RSS.

Baseline Policy

• Start from the defaults
• Increase them only once you can see CPU usage or queue imbalance
• Cranking them to the maximum for no reason can increase interrupt and DPC load

6.7 Interrupt Moderation / Interrupt Moderation Rate

This setting throttles interrupt frequency, trading CPU load against latency.

Tendencies

• Higher / Adaptive -> CPU tends to get an easier time, but latency tends to grow
• Lower / Off -> Latency tends to drop, but CPU and DPC load tend to rise

Baseline Policy

• Start from the default or Adaptive
• If jitter on small packets bothers you, evaluate Low or Off
• For bulk transfers, the default is usually the more straightforward choice

flowchart TB
    accTitle: The tug-of-war in Interrupt Moderation
    accDescr: A diagram showing the tug-of-war where setting Interrupt Moderation higher or to Adaptive gives the CPU an easier time but tends to grow latency, while setting it lower or Off drops latency but tends to raise CPU and DPC load.
    im1["Interrupt Moderation"] -->|"higher / Adaptive"| cpuok["CPU tends to get an easier time"]
    cpuok -.-> lat1["Latency tends to grow"]
    im1 -->|"lower / Off"| latok["Latency tends to drop"]
    latok -.-> cpu2["CPU and DPC load tend to rise"]

Figure 14: Throttling interrupt frequency trades CPU against latency; start the evaluation from the default or Adaptive.

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

These settings change the depth of the rings and buffers.

What They Help

• Burst tolerance
• Sustained throughput
• Avoiding drops

Side Effects

• Memory usage grows
• Deeper queues can add queueing delay

Baseline Policy

• Increase them only when you can see drops or buffer shortage
• Avoid cranking them to the maximum on a hunch

flowchart TB
    accTitle: When to increase buffer depth
    accDescr: A diagram showing that deeper buffers help burst tolerance and drop avoidance while increasing memory usage and possibly queueing delay, so the decision is to increase them only when drops or buffer shortage are visible.
    obs1["Drops or buffer shortage are visible"] -->|"only when visible"| inc1["Increase the buffers"]
    inc1 -.-> side1["Memory usage and queueing delay can grow"]
    non1["Cranking to the maximum on a hunch"] -.->|"avoid"| inc1

Figure 15: Increase buffers only when the symptom shows up in the numbers, and avoid maxing them out on a hunch.

6.9 Flow Control

This setting governs sending and receiving 802.3x pause frames.

Baseline Policy

• It is a candidate if you want to reduce drops
• However, pause can also spread congestion elsewhere
• Look at it carefully in low-latency scenarios
• Think about it together with the design of the whole network

flowchart TB
    accTitle: The two faces of Flow Control
    accDescr: A diagram showing that Flow Control pause frames can work in the direction of reducing drops while also spreading congestion elsewhere, so the decision has to be made together with the design of the whole network.
    fc1["pause frame (Flow Control)"] -->|"can be effective"| less1["In the direction of reducing drops"]
    fc1 -.->|"can also spread"| cong1["Congestion elsewhere"]
    fc1 --> tot1["Decide together with the whole network design"]

Figure 16: Flow Control reduces drops but can also spread congestion, so never judge it in isolation.

7. Settings Around VLAN, QoS, and Virtualization

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

This is the band that deals with 802.1Q VLAN and 802.1p Priority.

Baseline Policy

• Pay attention to it only when you genuinely use VLAN or QoS
• In a plain access port environment, the defaults are fine
• Be careful with configurations that add tags on their own, since they make isolation harder

7.2 VMQ / VMMQ / SR-IOV

These settings only mean something on a Hyper-V host or a virtualization platform.

Baseline Policy

• Do not treat them as 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 produces the right answer

flowchart TB
    accTitle: The unit of evaluation for VMQ and SR-IOV
    accDescr: A diagram showing that VMQ and SR-IOV only mean something on a Hyper-V host or virtualization platform, that they have to be evaluated together with the vSwitch configuration, queue assignment, and guest-side settings, and that looking at only one side rarely produces the right answer.
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["Means something on a Hyper-V host"]
    hv1 --> setb["Evaluate with vSwitch, queues, and the guest side together"]
    vm1 -.->|"not treated as"| dt1["Ordinary desktop tuning"]

Figure 17: Virtualization settings can only be evaluated when you look at the host, the vSwitch, and the guest as one whole.

7.3 RDMA / DCB / PFC Are a Different World

This area, which includes SMB Direct and lossless Ethernet, is a considerably different world.

Baseline Policy

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

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

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

This setting lowers power consumption while the link is idle, for the sake of power saving.

How to Look at It

• It is not a setting that makes things faster
• It does help power consumption
• Depending on the peer device and cabling conditions, it becomes a candidate for isolating link instability or a downshift to 100Mbps

Baseline Policy

• For general use, the default is fine
• For link instability, drops to 100Mbps, or a low-latency focus, it is the first isolation candidate

flowchart TB
    accTitle: Where EEE fits
    accDescr: A diagram showing that EEE is a power-saving setting that lowers power consumption while the link is idle rather than a setting that makes things faster, and that depending on the peer device and cabling conditions it becomes a candidate for isolating link instability or a downshift to 100Mbps.
    eee1["EEE / Green Ethernet"] --> sv3["Lowers power consumption while idle"]
    eee1 -.->|"not a setting that makes things faster"| spd1["Speed and performance"]
    eee1 -.->|"depending on the peer and cabling"| tgl1["Isolation candidate for instability and downshift"]

Figure 18: EEE is a power-saving setting, and for link instability or a drop to 100Mbps it is the first isolation candidate.

8.2 Selective Suspend / Device Sleep / Link Control During Standby

Put plainly, these settings decide how deeply the NIC sleeps while idle or during system sleep.

Baseline Policy

• On laptops, start from the defaults
• If you have resume trouble, suspect these first
• On equipment-control PCs and in 24/7 operation, turning them off is often the clearer choice

8.3 Wake on Magic Packet / Wake on Pattern Match

These settings let a sleeping PC be woken over the network.

Baseline Policy

• Enable Magic Packet if you need Wake on LAN
• Disable it if you do not
• Use Pattern Match only when the need is clear

Turning it on only at the NIC often does not wake the machine. Line up the BIOS / UEFI side and the Power Management tab as well.

flowchart TB
    accTitle: The conditions under which Wake on LAN works
    accDescr: A diagram showing that Wake on LAN only works when the NIC Magic Packet setting, the BIOS or UEFI side, and the Power Management tab side all line up, so all three places need to be checked together.
    m1["NIC Magic Packet setting"] --> wol1["Wake on LAN works"]
    m2["BIOS / UEFI side setting"] --> wol1
    m3["Power Management tab side"] --> wol1
    wol1 -.-> pt2["Pattern Match easily causes unintended wakes"]

Figure 19: WoL only works when the NIC, the BIOS/UEFI, and the power management tab all line up.

8.4 ARP Offload / NS Offload

These settings let the NIC answer a minimum set of requests on the system’s behalf during sleep.

Baseline Policy

• Normally enabled or at the default is fine
• They are often touched temporarily when isolating sleep-related compatibility issues

8.5 Settings on the Power Management Tab

Separately from the Advanced tab, NIC properties have a Power Management tab. It matters more than it looks.

The three you see most often are these.

• 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 Policy

• For resume failures, suspect Allow the computer to turn off this device... first
• To avoid unintended wakes, enable Only allow a magic packet...
• If you do not need Wake on LAN at all, disabling every wake option is fine

flowchart TB
    accTitle: How to read the Power Management tab
    accDescr: A diagram showing the decision of suspecting the allow-the-computer-to-turn-off-this-device setting first for resume failures, enabling the magic-packet-only wake setting to avoid unintended wakes, and disabling every wake option when Wake on LAN itself is not needed.
    q4["What is the actual problem"] -->|"resume failure"| a1["Suspect the power-off permission setting first"]
    q4 -->|"avoid unintended wakes"| a2["Wake only on Magic Packet"]
    q4 -->|"WoL not needed at all"| a3["Disable every wake option"]

Figure 20: On the Power Management tab, the first place to touch is determined by the kind of problem you have.

9. Other Settings You See Often but Rarely Touch

9.1 Network Address / Locally Administered Address

This setting overrides the MAC address by hand.

Baseline Policy

• Do not touch it normally
• It is not a performance setting
• Use it only in lab environments or for special requirements

9.2 Adaptive Inter-Frame Spacing

A very old-school setting. On modern switched full-duplex Ethernet it is not a major factor.

Baseline Policy

• On a modern ordinary LAN, leave it at the default
• Touch it only for old equipment or special environments where the vendor says to

9.3 Header Data Split

Mainly a server-oriented setting, in the category of helping CPU processing by handling packet headers and payloads separately.

Baseline Policy

• Server oriented and workload specific
• On general clients, leave it at the default

9.4 Low Latency Interrupts

Some vendors expose an item such as Low Latency Interrupts.

Baseline Policy

• Use it only when measurement shows it wins
• This is not a band to switch On based on vibes

9.5 Old Items Such as TCP Chimney Offload and IPsec Task Offload

On older NICs and drivers, you sometimes see items like these.

Baseline Policy

• Do not touch them, do not use them today
• Do not get pulled along by compatibility concerns or old documentation

flowchart TB
    accTitle: The shared stance for the items in Chapter 9
    accDescr: A diagram showing the shared stance that overriding the MAC address, old-school settings, server-oriented settings, and legacy offload items are normally left at their defaults and touched only when there is a vendor instruction or a clear requirement backed by measurement.
    rare1["The items listed in Chapter 9"] --> keep1["Normally left at the default, untouched"]
    keep1 -->|"touch them only"| cond1["When there is a vendor instruction or a clear requirement"]
    cond1 -.-> meas1["Use only when measurement shows it wins"]

Figure 21: A band you normally leave alone even when you notice it, touched only with clear instructions or requirements plus measurement.

10. Rough Guidance by Goal

Below, the phrases “evaluate disabling” and “disable as a candidate” come up repeatedly. They do not mean “turn it off.” They mean make it a subject of evaluation. The substance is exactly the ground rules from 3.3 and 3.4, and concretely it is these four steps.

1. Save the settings before the change (the Export-Csv in 12.1)
2. Disable exactly one item (3.3)
3. Measure the metrics you decided on in 3.4 (throughput, latency, CPU, NIC statistics, resume stability)
4. Restore it if it had no effect

Skip step 4 and meaningless changes pile up, making the next round of isolation harder. Read each item below as a candidate list for running these four steps.

flowchart TB
    accTitle: The four steps of evaluating a disable
    accDescr: A diagram showing the loop of the four steps for evaluating a disable: save the settings before the change, disable exactly one item, measure the metrics you decided on, and restore it if it had no effect.
    h1["Save the settings before the change"] --> h2["Disable exactly one item"]
    h2 --> h3["Measure the metrics you decided on"]
    h3 -->|"if it had no effect"| h4["Restore it"]
    h4 -.->|"on to the next candidate"| h2

Figure 22: “Evaluate disabling” does not mean turn it off; it means running these four steps and measuring.

10.1 An Ordinary Desktop or Laptop PC

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

In other words, the baseline is not deviating from the defaults to begin with.

10.2 NAS, Backup, and Bulk Copies

• Speed & Duplex: Auto
• Jumbo: evaluate if you can line it up on a dedicated path
• Checksum Offload: enabled
• LSO: enabled
• RSC: enabled
• RSS: enabled
• RSS queues: raise a little if needed
• Receive / Transmit Buffers: raise a little if there are drops
• Interrupt Moderation: default or slightly higher
• EEE: evaluate disabling if stability comes first

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

10.3 Industrial Cameras, Equipment Control, and a Low-Latency Focus

• Speed & Duplex: Auto by default. Pin it to match the peer if you must
• Jumbo: evaluate if the camera, the NIC, and the switch all line up
• Checksum Offload: enabled first
• LSO: evaluate disabling temporarily if the send path looks like a compatibility problem
• RSC: a candidate for disabling if low latency or observation comes first
• Interrupt Moderation: evaluate Low / Off
• Buffers: do not overdo it
• Flow Control: the side effects of pause need evaluation
• EEE / Green Ethernet: a candidate for disabling
• Selective Suspend and power management: candidates for disabling

Settings that optimize throughput are not necessarily an advantage for low latency.

10.4 A Hyper-V Host

• VMQ / VMMQ / SR-IOV: evaluate according to the configuration
• RSS: important for host-side traffic
• RSC: constrained depending on the vSwitch configuration
• QoS / VLAN: align with the vSwitch design
• Flow Control / PFC: think about it together with the storage and RDMA design

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

10.5 Temporary Settings for Troubleshooting

When isolating a fault, returning to a simple world for a while is a strong move.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: disabled
• EEE: disabled
• LSO: temporarily disabled
• RSC: temporarily disabled
• Interrupt Moderation: default or lower
• Wake and power save: disabled if not needed
• Settings before the change: always saved

During isolation, simplifying the behavior beats optimizing the performance.

11. First Places to Look, by Symptom

11.1 It Should Be 1Gbps or 2.5Gbps but Comes Up at 100Mbps

The order to look is roughly this.

1. The cable
2. The dock / USB NIC / converter adapter
3. The switch port
4. A driver update
5. EEE / Green Ethernet
6. Return Speed & Duplex to Auto
7. If none of that works, try pinning it to match the peer

Jumping straight to a manual pin is the last move.

flowchart TB
    accTitle: The order to look when a link drops to 100Mbps
    accDescr: A diagram showing the order of looking at the cable, the dock or USB NIC, the switch port, a driver update, isolating EEE, returning to Auto Negotiation, and only if none of that works pinning the speed to match the peer.
    s1["The cable"] --> s2["dock / USB NIC / converter"]
    s2 --> s3["The switch port"]
    s3 --> s4["A driver update"]
    s4 --> s5["Isolating EEE"]
    s5 --> s6["Speed & Duplex back to Auto"]
    s6 -->|"if none of that works"| s7["Pin it to match the peer"]

Figure 23: Investigate a downshift starting from the physical layer, and keep manual pinning as the last resort.

11.2 Bulk Transfers Are Slow but ping Looks Normal

These are the things to look at.

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame (if the path is dedicated)
• Drops and 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

These are the five to check.

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Whether the buffers have been piled up too high

In this band, optimizations that batch processing together can end up increasing the delay you perceive.

11.4 The NIC Disappears After Sleep Resume, or Cannot Connect for Several Seconds

Centered on power, these are the five to look at.

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

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

11.5 A Packet Capture Shows Masses of Checksum Errors

Before rushing to declare “the line is broken,” check these.

• Whether Checksum Offload is enabled
• Whether LSO is enabled
• Whether the capture is before transmission or on the wire
• Whether it looks the same from another host or a mirror port

Checksum errors in a local capture really are, very often, just how offload looks.

A note on the third item, “whether the capture is before transmission or on the wire.” When you capture on your own PC, you see packets before the NIC fills in the checksum. With offload enabled, the checksum field is still empty or holds a provisional value, so the analyzer naturally reports it as invalid. The packet that actually went out on the cable being correct is a perfectly ordinary outcome.

flowchart TB
    accTitle: Why a local capture looks like a checksum error
    accDescr: A diagram showing the mechanism where a capture on your own PC sees packets before the NIC fills in the checksum so the analyzer reports them as invalid when offload is enabled, while the packet that actually went out on the cable can be correct.
    lc1["Capture on your own PC"] --> pre1["Sees packets before the checksum is filled in"]
    pre1 --> bad1["The tool reports them as invalid"]
    wire1["Look at the wire from a mirror port"] --> okw1["The actual packets are correct"]
    okw1 -.-> ver1["Comparing both confirms it is how offload looks"]

Figure 24: A local capture point sits upstream of the NIC, so with offload enabled the error display is usually an artifact of where you are looking.

The tools used to confirm this are roughly these three.

pktmon logs can be converted to pcapng, so you can open them directly in Wireshark.

pktmon etl2pcap log.etl --out capture.pcapng

If it is “checksum errors locally, clean on the mirror port,” that settles it: it is how offload looks. Confirm that far before touching any settings.

11.6 Only the Hyper-V VMs Are Slow, or CPU Load Is Skewed

What to look at is not just desktop-style RSS.

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

In virtualization, drawing a diagram of who is handling the packets makes it easier to sort out.

12. Practical Notes for Checking and Changing Things in PowerShell

12.1 Save the Current State First

Backing things up before a change 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 Properties

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

12.3 Look at RSS, RSC, and Statistics

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

12.4 Examples of Changing a Setting

The actual display names differ per NIC, so list them first and then make the change.

# Example: change Jumbo Packet (the value differs 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 A Connectivity Check for Jumbo

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

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

1472 and 8972 are the payloads after subtracting the IP and ICMP headers. The 9014 Bytes shown in the driver UI and these ping numbers do not match.

12.6 Practical Notes

• Some settings require disabling and re-enabling the adapter or a reboot
• DisplayName can be localized
• Even within the same vendor, item names can change between driver versions
• If you automate with PowerShell, it is safer to enumerate the values on the actual device first and then write the script

13. Summary

Judging by the item names alone, every Windows NIC advanced setting looks powerful. In reality, though, this is a world where the right answer depends on which of throughput, latency, CPU, power, and compatibility you are going after.

The key points of this article are these.

• Speed & Duplex stays on Auto by default
• Jumbo only when it lines up end-to-end
• Checksum / RSS / LSO / RSC are strongest at their defaults as a rule
• Interrupt Moderation is a trade-off between throughput and latency
• Buffers only as much as you need
• EEE / Selective Suspend / wake settings are about power and resume
• VMQ / SR-IOV are about Hyper-V
• Do not touch the old offload items

And the three most important things are these.

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

NIC settings are not a magic switch that makes things faster. But when the goal lines up, they work quite well. Conversely, when the goal is off, they backfire just as reliably.

flowchart TB
    accTitle: The three most important patterns
    accDescr: A diagram showing that if you keep the three patterns of deciding what you want to improve, changing exactly one item at a time, and comparing before and after with numbers, NIC settings work quite well as long as the goal lines up.
    r1["Decide what you want to improve"] --> r2["Change exactly one item at a time"]
    r2 --> r3["Compare before and after with numbers"]
    r3 --> eff1["Works quite well when the goal lines up"]
    r1 -.->|"when the goal is off"| back1["Backfires just as reliably"]

Figure 25: Keep the three patterns of goal, one item, and numbers and it works; miss them and it backfires.

14. References

The following are the official and vendor documents used as the foundation for this article. Windows and NIC drivers have a lot of terminology drift, so in the end it is safest to check against your own NIC’s driver name and version.

• 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
• Microsoft Learn: Packet Monitor (Pktmon)
• Microsoft Learn: pktmon etl2pcap
• Microsoft Learn: UDP Segmentation Offload (USO)
• Microsoft Learn: UDP Receive Segment Coalescing Offload (URO)
• 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 article 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.

Frequently Asked Questions

Common questions about the topic of this article.

Should Large Send Offload (LSO) be disabled?

Normally it should stay enabled. LSO is the mechanism that hands large TCP send buffers to the NIC so the NIC splits them into individual frames, and it helps both throughput and CPU usage on send-heavy traffic. Disabling it carelessly tends to waste CPU. The cases worth considering are isolation work, where you turn it off temporarily to see the difference when a specific application or driver looks like a compatibility problem, and situations such as industrial cameras or equipment control where you want to evaluate how the send path behaves. Even when you disable it for isolation, the rule is to restore the default once you find the cause lies elsewhere.

What is Receive Segment Coalescing (RSC), and should it be disabled?

RSC is the setting that lets the NIC coalesce multiple received TCP segments on the receive side, also known as Large Receive Offload. It helps receive throughput and reduces CPU usage, so enabling it is the baseline policy when receive performance matters. On the other hand it can work against you for low latency and per-packet observation, and it slightly changes how you interpret packet captures and timing measurements. It becomes a candidate for evaluation when you want to shave latency off small request/response traffic, or in environments that prioritize low latency and observability. Get-NetAdapterRsc shows the current state.

What should I check when a link comes up at 100Mbps even though it should be 1Gbps?

Pinning Speed & Duplex by hand is the last resort. The order to look is: the cable first, then the dock / USB NIC / converter adapter, the switch port, a driver update, isolating EEE / Green Ethernet, returning Speed & Duplex to Auto, and only if none of that works, pinning it to match the peer. Downshifts to 100Mbps and link drops are more often caused by the physical layer or the peer device than by NIC settings. A state where one side is pinned and the other is on Auto causes duplex mismatch, which leads to reduced speed, retransmissions, and abnormal delays.

Which Windows NIC advanced settings should I actually enable?

On an ordinary desktop or laptop PC, the baseline is not to deviate from the defaults. Keep Speed & Duplex on Auto, keep Checksum Offload / LSO / RSC / RSS enabled or at their defaults as a rule, and use Jumbo Packet only when the NIC, the peer, and every switch in between line up end-to-end. EEE and Selective Suspend are power-saving settings, not settings that make things faster. When you do change something, decide first what you want to improve (throughput, latency, CPU, power consumption), change exactly one item at a time, and compare before and after with numbers. That is the ironclad rule.

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.