Windows NIC 詳細設定指南 - RSS/LSO/EEE/Wake on LAN

Windows 的 NIC [Advanced] 索引標籤上，排著一長串陌生的字眼。 Jumbo Packet、Large Send Offload、Interrupt Moderation、Receive Side Scaling、Flow Control、Energy Efficient Ethernet。光看名字會想把全部都啟用，但實際上正確答案會隨著想優先什麼而改變。

• 是想提高大量傳輸的吞吐量
• 是想把小封包的延遲壓低
• 是想降低 CPU 使用率
• 是想讓睡眠喚醒與 Wake on LAN 穩定下來
• 是想釐清驅動程式或交換器的相容性問題

這一層還模糊時就去做「總之全部 On」「總之 Jumbo 9014」「慢就固定成 1Gbps Full」，出事的機率相當高。

flowchart TB
    accTitle: 目的模糊就動手容易出事
    accDescr: 在想優先什麼還模糊時就總之全部 On、啟用 Jumbo 或固定速度，容易出事，而先決定要優先什麼，正確答案就會跟著改變的圖。
    vague1["想優先什麼還模糊"] --> hasty1["總之全部 On、Jumbo、固定"]
    hasty1 --> acc1["出事的機率相當高"]
    clear1["先決定要優先什麼"] -->|"正確答案會跟著改變"| pick3["能收斂出該動的設定"]

圖 1: 不先決定目的就去動看起來很強的設定會出事，決定了目的就能收斂該動的地方。

本文主要以 Windows 10 / 11 / Windows Server 的有線 Ethernet 介面卡為對象，梳理實務上動 NIC 詳細設定時的思考方式。 設定的意義、把值調高／調低／啟用／停用之後容易發生什麼、什麼場合才該動它，都寫成可以一次看完的形式。

另外，NIC 的顯示名稱與可選的值 會因廠商與驅動程式而有很大差異。 Jumbo Packet 可能寫成 Jumbo Frames，Receive Buffers 可能寫成 Receive Descriptors，Priority & VLAN 可能寫成 Packet Priority & VLAN。本文會把意思相近的項目歸在一起談。

這篇文章怎麼讀

全文有 14 章，篇幅不短，先給一條動線。不需要全部讀完。

最常見的讀法，應該是「從症狀切入，第 11 章 → 對應設定的章節 → 第 10 章把設定收回去」。

flowchart TB
    accTitle: 最常見的閱讀動線
    accDescr: 從症狀切入，先看第 11 章依症狀鎖定的檢查點，再到對應設定的章節確認意義，最後用第 10 章依目的分類的方針把設定收回去的閱讀動線的圖。
    sym1["從症狀切入"] --> ch11["第 11 章（依症狀鎖定的檢查點）"]
    ch11 --> chd1["對應設定的章節（第 5〜9 章）"]
    chd1 --> ch10["第 10 章（用依目的的方針收回去）"]

圖 2: 從症狀進入第 11 章，經過對應設定的章節，再用第 10 章的方針收回去，是典型的動線。

縮寫小辭典

為了方便一邊對照設定畫面一邊閱讀，這裡先整理本文出現的縮寫。

1. 先講結論

先把實務上比較不會錯的結論放在前面。

• Speed & Duplex 基本上維持 Auto。遇到掉到 100Mbps 的問題時，一開始就衝去固定成 1.0 Gbps Full Duplex 是最後才做的事。
• Checksum Offload／RSS／LSO／RSC 原則上啟用或維持預設值。隨手全部關掉，反而容易白白吃掉 CPU。
• Jumbo Packet 只在 end-to-end 全部對齊時才用。只把 NIC 設成 9014，中途路徑還是 1500，就是個陷阱。
• Interrupt Moderation 是 throughput 與 latency 的拔河。調高之後 CPU 會輕鬆，但延遲會增加。
• Flow Control 有時會往減少 drops 的方向發揮作用，但也可能把壅塞擴散出去。
• EEE／Green Ethernet／Selective Suspend 是為了省電的設定，不是讓速度變快的設定。
• VMQ／SR-IOV 是給 Hyper-V 主機用的，不是讓一般桌上型電腦變快的魔法。
• Wake on Pattern Match 很容易成為非預期 wake 的原因，所以如果只是想要 Wake on LAN，統一改用 Magic Packet 比較安全。
• TCP Chimney Offload 之類的老項目，現在最好別碰。

總之，NIC 的詳細設定不是「把看起來很強的東西全部啟用」的地方。 它是先決定要拿到吞吐量、延遲、CPU、耗電量、相容性當中的哪一項，再一個一個動的地方。

flowchart TB
    accTitle: 詳細設定索引標籤的定位
    accDescr: NIC 的詳細設定不是把看起來很強的東西全部啟用的地方，而是先決定要拿吞吐量、延遲、CPU、耗電量、相容性當中的哪一項，再一個一個動的地方的圖。
    allon1["把看起來很強的全部啟用"] -.->|"不是這種地方"| tab1["NIC 的詳細設定"]
    dec1["決定要拿哪一個軸"] --> one2["一個一個動"]
    one2 --> tab1

圖 3: 詳細設定索引標籤，是先決定要拿的軸再一個一個動的地方。

圖中實線表示始終成立的關係，虛線表示附帶條件的關係（成立條件寫在詳細頁面中各關係的說明中）。關係的完整清單（共 26 條，附依據與可信度）以及主要概念的定義，彙整在知識地圖詳細頁面（日文）。資料：JSON-LD / Turtle

2. 在哪裡查看設定

2.1 用 GUI 查看

從網路連線進入

1. 執行 ncpa.cpl
2. 在目標介面卡上按右鍵
3. 內容 → 設定
4. 進階 (Advanced) 索引標籤

從裝置管理員進入

1. 裝置管理員
2. 網路介面卡
3. 在目標 NIC 上按右鍵 → 內容
4. 進階索引標籤

排在這裡的項目就是本文的主角。 不過，Power Management 索引標籤的設定在實務上也相當有效，後半段會談到。

2.2 用 PowerShell 查看

用 PowerShell 比較容易一次列出目前的值，也比較容易在變更前先備份。

Get-NetAdapter

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

有些 NIC 的 RegistryKeyword 會是標準化的名稱，看起來像 *RSS、*VMQ、*SRIOV、*EEE。 不過，DisplayName 與 DisplayValue 取決於驅動程式。要寫變更用的指令碼時，先在實機上看過一覽比較安全。

flowchart TB
    accTitle: 用 PowerShell 查看時的順序
    accDescr: 在寫變更用的指令碼之前，先理解 DisplayName 與 DisplayValue 取決於驅動程式，因此要先在實機上看過一覽再動筆的安全順序的圖。
    lst1["在實機上看一覽"] --> dep1["確認顯示名稱取決於驅動程式"]
    dep1 --> scr1["然後才寫變更用的指令碼"]
    scr1 -.-> bk1["變更前的備份也要做"]

圖 4: 顯示名稱取決於驅動程式，所以先看實機的一覽再寫指令碼。

3. 動手前的大原則

動 NIC 設定之前，這幾點沒抓好，大概就會陷入泥沼。

3.1 先決定「想改善什麼」

同樣是「網路很慢」，內容其實完全不同。

• 大型檔案複製很慢 → throughput、RSS、RSC、LSO、Jumbo、緩衝區
• 小型 request/response 反應拖沓 → Interrupt Moderation、RSC、EEE、佇列深度
• CPU 很高 → 卸載（offload）、RSS、RSC、中斷
• 從睡眠喚醒後不對勁 → Selective Suspend、Power Management、WoL
• 偶爾斷線／變成 100Mbps → 網路線、對端設備、Speed & Duplex、EEE、驅動程式

目的不同卻動同樣的設定，不但不會改善，還會惡化。

flowchart TB
    accTitle: 先把「很慢」的內容分開
    accDescr: 同樣是網路很慢的症狀，內容其實完全不同，要先決定想改善什麼再去動對應的設定群，否則不但不會改善還會惡化的圖。
    slow1["網路很慢"] --> split1["先把內容分開"]
    split1 --> aim1["只動符合目的的設定群"]
    slow1 -.->|"沒分開就動手"| worse1["不但不會改善還會惡化"]

圖 5: 不先把症狀的內容分開就動手，同樣是「很慢」也會產生反效果。

3.2 先懷疑實體層與對端設備

有些問題本來就不是靠 NIC 設定能修好的。

• 網路線不良
• 交換器／路由器／dock 的相容性
• 過舊的 firmware
• USB NIC 供電不足
• 連接埠側的錯誤
• 封包遺失與重送

尤其是掉到 100Mbps、連線反覆斷續、只有大量傳輸會壞掉這幾種，先看實體層與對端，比先看設定快。

flowchart TB
    accTitle: 先看實體層與對端設備
    accDescr: 掉到 100Mbps、連線反覆斷續、只有大量傳輸會壞掉這類症狀，先懷疑網路線與對端設備等實體層，比先看 NIC 設定更快的圖。
    symp1["降速、連線斷續等症狀"] --> phys1["先看網路線、對端設備、實體層"]
    phys1 -->|"還是沒解決"| nicw1["進到 NIC 設定的釐清"]
    phys1 -.-> nofix1["也有本來就不是設定能修好的問題"]

圖 6: 連線類的症狀，先懷疑實體層與對端設備比先看設定更快。

3.3 一次只改一個項目

把 Jumbo、LSO、RSC、RSS、EEE 一口氣全改，就會搞不清楚是哪一項起了作用。 先把變更前的設定寫出來，一項一項改，再量測變化，這是基本做法。

3.4 先決定要量測什麼

至少這幾項是會想看的。

• 連線速度（1G／2.5G／10G 等）
• 吞吐量
• 延遲
• CPU 使用率
• NIC 的統計（drop／error／buffer shortage）
• 從睡眠喚醒的穩定性

設定變更不能只靠體感，用數字看比較有說服力。

flowchart TB
    accTitle: 一次改一項再用數字比較
    accDescr: 先寫出變更前的設定，只改一個項目，量測事先決定好的指標，再用數字而不是體感來比較，這個設定變更基本流程的圖。
    w1["寫出變更前的設定"] --> w2["只改一個項目"]
    w2 --> w3["量測決定好的指標"]
    w3 --> w4["用數字而不是體感比較"]

圖 7: 變更一次只改一項，前後用數字比較，這是基本的套路。

4. 主要設定一覽表

先放一張可以一次看完各設定角色的表。

5. 連線與訊框大小相關的設定

5.1 Speed & Duplex

這是關於連線速度與全雙工／半雙工協商的設定。顯示名稱有 Speed & Duplex、Link Speed、Link Speed & Duplex 等。

這個設定在做什麼

在 Ethernet 中，NIC 與對端設備會決定用哪個速度、哪種 duplex 通訊。

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

之類的選項很常見。

改動之後會有什麼變化

設成 Auto

• 在現代設備之間，基本上這樣最穩定
• 1000BASE-T 以上，很多場合是以 Auto 為前提
• 與 EEE 或 master/slave 的協商也比較容易一致

手動固定

• 面對舊交換器，或對端已經被強制固定的設備時，相容性有時會改善
• 不過，只有一邊固定／只有一邊 Auto 這種狀態是出事的根源
• 一旦發生 duplex mismatch，就會造成降速、重送與異常延遲

實務上的基本方針

一般維持 Auto 就好。 「跑不到 1Gbps 就固定成 1Gbps Full」看起來很有力，但多半沒打中要害。

flowchart TB
    accTitle: 單邊固定招來的 duplex mismatch
    accDescr: 只有一邊固定、另一邊維持 Auto 的狀態會造成 duplex mismatch，導致降速、重送與異常延遲，因此現代設備之間基本上維持 Auto 最穩定的圖。
    mix1["只有一邊固定、只有一邊 Auto"] --> mm1["duplex mismatch"]
    mm1 --> sl2["降速、重送、異常延遲"]
    auto1["兩邊都是 Auto"] -->|"現代設備之間"| stb1["基本上這樣最穩定"]

圖 8: 固定與 Auto 混在一起會造成 duplex mismatch，所以一般兩邊都設成 Auto。

5.2 Jumbo Packet / Jumbo Frames

這是使用比標準更大的 Ethernet 訊框的設定。顯示名稱有 Jumbo Packet、Jumbo Frames、Jumbo Packet Size 等。

這個設定在做什麼

一般的 Ethernet 多半以 MTU 1500 為前提運作。啟用 Jumbo Frame 之後，就能使用約 9000 位元組的大型訊框。

不過，這裡的名稱陷阱很多。

• 驅動程式有時會像 9014 Bytes 那樣顯示訊框大小
• 作業系統與工具有時會像 MTU 9000 那樣以 L3 的視角來看
• 交換器有時會連 CRC 與 VLAN 標籤一起計算

只把數字並排比較，非常容易卡住。

flowchart TB
    accTitle: Jumbo 數字的計算方式差異
    accDescr: 同樣的 Jumbo 設定，驅動程式看的是訊框大小，作業系統與工具看的是 L3 視角的 MTU，交換器則可能連 CRC 與 VLAN 標籤一起算，只把數字並排比較就會卡住的圖。
    drv1["驅動程式：顯示訊框大小"] --> cmp2["同一件事用不同的計算方式在看"]
    osv1["作業系統、工具：MTU 的 L3 視角"] --> cmp2
    sw1["交換器：含標籤與 CRC"] --> cmp2
    cmp2 --> trap1["只把數字並排比較就會卡住"]

圖 9: 驅動程式、作業系統、交換器的計算方式不同，所以 Jumbo 的數字不要並排比較。

改動之後會有什麼變化

調大／啟用

• 送出大量資料時封包數會減少
• header 的處理次數減少
• CPU 使用率容易下降
• 另一方面，每個 packet 的佔用時間會變長
• 路徑上只要有一段不支援，就會造成 drop 或 fragmentation

改回標準／停用

• 相容性最高
• 封包數會增加
• 大量傳輸時 CPU／header overhead 容易增加

實務上的基本方針

Jumbo 要在 end-to-end 全部對齊之後才有意義。

• 自己的 NIC
• 對端的 NIC
• 中途的交換器
• 如果中間夾了 VLAN 或虛擬交換器，還要算上那份 overhead

只要其中一段還是 1500，不但沒有效果，還會變成問題的來源。

flowchart TB
    accTitle: Jumbo 要 end-to-end 對齊才有意義
    accDescr: Jumbo Frame 要自己的 NIC、中途的交換器、對端的 NIC 都 end-to-end 對齊才有意義，只要其中一段還是 1500，不但沒有效果還會變成問題來源的圖。
    myn1["自己的 NIC"] --> mid1["中途的交換器"]
    mid1 --> yrn1["對端的 NIC"]
    yrn1 --> okj1["全部對齊才有意義"]
    mid1 -.->|"其中一段還是 1500"| ngj1["沒有效果、變成問題來源"]

圖 10: Jumbo 的前提是路徑上所有人都對齊，只要有一處還是 1500 就會產生反效果。

5.3 Gigabit Master / Slave Mode

這是 1000BASE-T 中，關於誰當 master、誰當 slave 來主導時脈的設定。一般電腦幾乎不會去動它。

基本方針

• 基本是 Auto
• 只在特定舊對端設備的 link quality 問題上才評估
• 除非有廠商指示，否則不把它當成效能 tuning 的旋鈕

5.4 Wait for Link 等連線狀態類的設定

Wait for Link 這類設定，關係到驅動程式是否等 auto negotiation 成功之後才回報 link 狀態。 Log Link State Event 則是把 link up/down 留在事件記錄檔裡的診斷用設定。

基本方針

• 一般電腦維持預設值就好
• 與其說是效能本身，不如說在開機時的呈現與 failover 診斷上有意義
• 不是一開始就該動的項目

6. 對 CPU 負載、吞吐量、延遲有效的設定

這一段是看起來最「像會有效」的區塊。實際上確實常常有效，但生效的方向分得很乾淨。

flowchart TB
    accTitle: 這一段設定生效的方向會分開
    accDescr: 對 CPU 負載、吞吐量、延遲有效的設定群，會乾淨地分成合併處理以拿到吞吐量與 CPU 的方向，以及細碎處理以拿到延遲的方向的圖。
    band1["看起來會有效的設定區塊"] --> dir1["合併處理的方向"]
    band1 --> dir2["細碎處理的方向"]
    dir1 -.-> g1["對吞吐量、CPU 有利"]
    dir2 -.-> g2["對延遲有利"]

圖 11: 同一區塊的設定，也會分成偏吞吐量與偏延遲兩種生效方向。

6.1 Checksum Offload

把 IP／TCP／UDP 的 checksum 計算集中到 NIC 的設定。

基本方針

• 原則啟用
• 想壓低 CPU 就保留它
• 擷取畫面上的 checksum error，多半是 offload 造成的顯示假象
• 為了釐清相容性而暫時關掉是可以的

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

由 NIC 端把大量的 TCP 送出資料切成細小 frame 的設定。

對什麼有效

• send-heavy 的 throughput
• 降低 CPU 使用率
• 較大量的連續送出

基本方針

• 通常啟用
• 懷疑特定應用程式或驅動程式相容性時，暫時停用看看差異

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

在接收端把多個 TCP segment 合併起來的設定。

對什麼有效

• 接收端的 throughput
• 降低 CPU 使用率

注意事項

• 在低延遲或以 packet 為單位的觀測上，有時會變得不利
• 擷取與時序觀測的解讀會稍微改變

基本方針

• 想拿到接收 throughput 就啟用
• 想看小型 request/response 的 latency 就列入評估

flowchart TB
    accTitle: RSC 的作用與評估的分界
    accDescr: RSC 由 NIC 端把接收到的多個 TCP 區段合併起來，對接收吞吐量與降低 CPU 有效，但在低延遲或以封包為單位的觀測上有時不利，因此會成為評估對象的圖。
    seg1["接收到的多個 TCP 區段"] --> coal1["由 NIC 端合併（RSC）"]
    coal1 --> up1["對接收吞吐量、CPU 有效"]
    coal1 -.->|"以低延遲、觀測為優先時"| dn1["可能不利，列入評估"]

圖 12: RSC 是把接收合併處理的設定，想拿的是延遲那一側時就要列入評估。

6.4 UDP 這邊較新的卸載（USO / URO）

在較新的 NIC 與作業系統上，UDP 的收送也可能看得到較新的 offload。

基本方針

• 就算出現了，也先不要偏離預設值
• 只有在驅動程式夠新、目標 workload 也很明確時才量測
• 排查問題時不要勉強去動它

6.5 Receive Side Scaling (RSS)

把接收處理分散到多個 CPU 的設定。在 multi-core 環境相當重要。

基本方針

• multi-core 上基本啟用
• 出現單一 CPU 被佔住的症狀時，先查看它
• 在 Hyper-V 或 high-throughput 的前面階段，它也容易成為主角

flowchart TB
    accTitle: 有沒有 RSS 讓接收處理不同
    accDescr: RSS 停用時接收處理集中在單一 CPU 容易塞住，啟用之後會分散到多個 CPU，在 multi-core 環境下吞吐量比較容易提升的圖。
    rin1["接收流量"] -->|"RSS 停用"| one3["集中在單一 CPU，容易塞住"]
    rin1 -->|"RSS 啟用"| sp2["分散到多個 CPU"]
    sp2 --> sc1["在 multi-core 上容易提升"]

圖 13: RSS 是把接收處理分散到多個 CPU 的機制，單一 CPU 被佔住的症狀要先查看它。

6.6 RSS Queues / RSS Processors / RSS Profile

決定 RSS 平行度的項目。

基本方針

• 從預設值開始
• 看到 CPU 使用率或 queue 分佈不均之後再增加
• 隨便加到最大，中斷與 DPC 負載有時會增加

6.7 Interrupt Moderation / Interrupt Moderation Rate

抑制中斷頻率，用 CPU 負載去換 latency 的設定。

傾向

• 調高／Adaptive → CPU 容易變輕鬆，但 latency 容易增加
• 調低／Off → latency 容易下降，但 CPU／DPC 負載容易上升

基本方針

• 以預設／Adaptive 為起點
• 在意小封包的 jitter 就評估 Low／Off
• 大量傳輸時，維持預設值多半比較直接了當

flowchart TB
    accTitle: Interrupt Moderation 的拔河
    accDescr: Interrupt Moderation 調高或設為 Adaptive 時 CPU 會變輕鬆但延遲容易增加，調低或關閉時延遲會下降但 CPU 與 DPC 負載容易上升的拔河的圖。
    im1["Interrupt Moderation"] -->|"調高 / Adaptive"| cpuok["CPU 容易變輕鬆"]
    cpuok -.-> lat1["延遲容易增加"]
    im1 -->|"調低 / Off"| latok["延遲容易下降"]
    latok -.-> cpu2["CPU / DPC 負載容易上升"]

圖 14: 抑制中斷頻率是 CPU 與延遲的交換，以預設或 Adaptive 為起點來評估。

6.8 Receive Buffers / Receive Descriptors 與 Transmit Buffers / Transmit Descriptors

改變環形緩衝區深度的設定。

生效的方向

• burst 耐受度
• sustained throughput
• 避免 drop

副作用

• 記憶體用量增加
• queue 變深，排隊延遲有時會增加

基本方針

• 只有在看得到 drop 或 buffer shortage 時才增加
• 避免憑感覺就開到最大

flowchart TB
    accTitle: 緩衝區該加深的時機
    accDescr: 把緩衝區加深對 burst 耐受度與避免 drop 有效，但記憶體用量會增加、排隊延遲也可能增加，因此只有在看得到 drop 或 buffer shortage 時才增加這個判斷的圖。
    obs1["看得到 drop 或 buffer shortage"] -->|"只有看得到時"| inc1["增加緩衝區"]
    inc1 -.-> side1["記憶體用量與排隊延遲可能增加"]
    non1["憑感覺開到最大"] -.->|"避免"| inc1

圖 15: 緩衝區只在症狀用數字看得到時才增加，避免憑感覺開到最大。

6.9 Flow Control

關於 802.3x pause frame 收送的設定。

基本方針

• 想減少 drop 時它是候選
• 不過 pause 有時會把另一種壅塞擴散出去
• 低延遲類的情境要謹慎看待
• 要和整體網路設計一起考量

flowchart TB
    accTitle: Flow Control 的兩面性
    accDescr: Flow Control 的 pause frame 有時會往減少 drop 的方向發揮作用，但 pause 也可能把另一種壅塞擴散出去，因此必須和整體網路設計一起考量的圖。
    fc1["pause frame（Flow Control）"] -->|"有時有效"| less1["往減少 drop 的方向"]
    fc1 -.->|"也可能擴散"| cong1["另一種壅塞"]
    fc1 --> tot1["和整體網路設計一起判斷"]

圖 16: Flow Control 一方面減少 drop，一方面也可能擴散壅塞，不能單獨判斷。

7. VLAN、QoS、虛擬化相關的設定

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

處理 802.1Q VLAN 與 802.1p Priority 的區塊。

基本方針

• 只有真的要用 VLAN／QoS 時才需要留意
• 單純的 access port 環境維持預設值就好
• 會自動加上標籤的組態會讓釐清原因變難，要注意

7.2 VMQ / VMMQ / SR-IOV

這是在 Hyper-V 主機或虛擬化平台上才有意義的設定。

基本方針

• 不把它當成一般的 desktop tuning
• 如果是 Hyper-V 主機，要連同 vSwitch 組態、queue 配置、來賓端設定一起評估
• 只看單邊很難得出正確答案

flowchart TB
    accTitle: VMQ / SR-IOV 的評估單位
    accDescr: VMQ 與 SR-IOV 是在 Hyper-V 主機或虛擬化平台上才有意義的設定，必須連同 vSwitch 組態、queue 配置、來賓端設定一起評估，只看單邊很難得出正確答案的圖。
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["在 Hyper-V 主機上才有意義"]
    hv1 --> setb["連同 vSwitch、queue、來賓端一起評估"]
    vm1 -.->|"不這樣處理"| dt1["一般的 desktop tuning"]

圖 17: 虛擬化類的設定，要把主機、vSwitch、來賓端一起看才評估得出來。

7.3 RDMA / DCB / PFC 是另一個世界

這一帶包含 SMB Direct 與 lossless Ethernet，是相當不同的世界。

基本方針

• 要和一般 1GbE／2.5GbE 的桌機調整分開來想
• 要把廠商文件與交換器側的設計一起核對

8. 省電、睡眠、Wake on LAN 相關的設定

8.1 Energy Efficient Ethernet (EEE) / Green Ethernet

為了省電，在連線 idle 時降低耗電量的設定。

怎麼看它

• 不是讓速度變快的設定
• 對耗電量有效
• 依對端設備與線材條件，它可能成為連線不穩或 100Mbps downshift 的釐清候選

基本方針

• 一般用途維持預設值也可以
• 連線不穩、變成 100Mbps、以低延遲為重時，它是第一個釐清候選

flowchart TB
    accTitle: EEE 的定位
    accDescr: EEE 是在連線 idle 時降低耗電量的省電設定，不是讓速度變快的設定，依對端設備與線材條件，它可能成為連線不穩或 100Mbps 降速的釐清候選的圖。
    eee1["EEE / Green Ethernet"] --> sv3["降低 idle 時的耗電量"]
    eee1 -.->|"不是讓速度變快的設定"| spd1["速度、效能"]
    eee1 -.->|"視對端與線材條件"| tgl1["連線不穩、降速的釐清候選"]

圖 18: EEE 是省電的設定，遇到連線不穩或變成 100Mbps 時，它是第一個釐清候選。

8.2 Selective Suspend / Device Sleep / Standby 時的連線控制

簡單說，就是在 idle 或睡眠時要讓 NIC 睡到什麼程度的設定。

基本方針

• 筆記型電腦從預設值開始
• 有喚醒後恢復的問題就先懷疑它
• 裝置控制用電腦或 24/7 運轉的場合，關掉反而比較好理解

8.3 Wake on Magic Packet / Wake on Pattern Match

這是透過網路喚醒睡眠中電腦的設定。

基本方針

• 需要 Wake on LAN 就啟用 Magic Packet
• 不需要就停用
• Pattern Match 只在必要性明確時才用

只把 NIC 打開卻叫不醒，是很常見的情況。BIOS／UEFI 側與 Power Management 索引標籤那邊也要一起看齊。

flowchart TB
    accTitle: Wake on LAN 生效的條件
    accDescr: Wake on LAN 不只需要 NIC 的 Magic Packet 設定，還要 BIOS 或 UEFI 側與 Power Management 索引標籤那邊都對齊才會醒來，因此必須把三個地方一起看齊的圖。
    m1["NIC 的 Magic Packet 設定"] --> wol1["Wake on LAN 生效"]
    m2["BIOS / UEFI 側的設定"] --> wol1
    m3["Power Management 索引標籤那邊"] --> wol1
    wol1 -.-> pt2["Pattern Match 容易造成誤喚醒"]

圖 19: WoL 要 NIC、BIOS/UEFI、電源管理索引標籤三處齊備才會生效。

8.4 ARP Offload / NS Offload

讓 NIC 在睡眠期間也代為做最低限度回應的設定。

基本方針

• 通常維持啟用／預設值就好
• 多半是在釐清睡眠相關的相容性時才暫時動它

8.5 Power Management 索引標籤的設定

除了 Advanced 索引標籤，NIC 的內容裡還有 Power Management 索引標籤。這裡也不起眼卻很重要。

常看的是以下三個。

• 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

基本方針

• 喚醒後恢復不良，就先懷疑 Allow the computer to turn off this device...
• 想避免誤喚醒，就啟用 Only allow a magic packet...
• 如果根本不需要 Wake on LAN，wake 類的全部停用即可

flowchart TB
    accTitle: Power Management 索引標籤怎麼看
    accDescr: 喚醒後恢復不良就先懷疑允許關閉裝置電源的設定，想避免誤喚醒就啟用只用 Magic Packet 喚醒的設定，根本不需要 Wake on LAN 就把 wake 類全部停用這個判斷的圖。
    q4["現在困擾的是什麼"] -->|"喚醒後恢復不良"| a1["先懷疑允許關閉電源的設定"]
    q4 -->|"想避免誤喚醒"| a2["只用 Magic Packet 喚醒的設定"]
    q4 -->|"根本不需要 WoL"| a3["wake 類全部停用"]

圖 20: Power Management 索引標籤，會依困擾的種類決定最先要動的地方。

9. 其他常看到但很少動到的設定

9.1 Network Address / Locally Administered Address

手動覆寫 MAC 位址的設定。

基本方針

• 平常不動它
• 不是效能設定
• 只在實驗室環境或特殊需求時使用

9.2 Adaptive Inter-Frame Spacing

歷史相當悠久的設定。在現代的 switched full-duplex Ethernet 上並不是主角。

基本方針

• 現代一般的 LAN 上維持預設值
• 只有在舊設備或特殊環境有廠商指示時才動

9.3 Header Data Split

主要給伺服器用，藉由把 packet header 與 payload 分開處理來幫助 CPU 的那一類設定。

基本方針

• 給伺服器／特定 workload 用
• 一般用戶端維持預設值

9.4 Low Latency Interrupts

有些廠商會有 Low Latency Interrupts 這樣的項目。

基本方針

• 只在量測後確實有贏時才用
• 不是憑氣氛就打開的區塊

9.5 TCP Chimney Offload / IPsec Task Offload 等老項目

在較舊的 NIC 或驅動程式上，有時會看到這類項目。

基本方針

• 現在不動、不用才是正解
• 不要被相容性或舊資料牽著走

flowchart TB
    accTitle: 第 9 章各項目的共同立場
    accDescr: 覆寫 MAC 位址、歷史悠久的設定、伺服器用設定與老舊的卸載項目，平常都維持預設值不動，只有在有廠商指示或明確需求並量測過時才動這個共同立場的圖。
    rare1["第 9 章列出的這些項目"] --> keep1["平常維持預設值不動"]
    keep1 -->|"會動它的時機"| cond1["有廠商指示、有明確需求時"]
    cond1 -.-> meas1["只在量測後確實有贏時才用"]

圖 21: 這是看到也平常不動的區塊，只有在有明確指示或需求並量測過時才出手。

10. 依目的分類的粗略方針

以下會多次出現「評估停用」「停用候選」這樣的寫法。這不是「把它停用」，而是把它列為評估對象的意思。內容就是 3.3 與 3.4 的大原則，具體來說是這 4 步。

1. 保存變更前的設定（12.1 的 Export-Csv）
2. 只停用一個項目（3.3）
3. 量測 3.4 決定的指標（吞吐量、延遲、CPU、NIC 統計、喚醒後的穩定性）
4. 沒有效果就改回原樣

少了第 4 步，沒有意義的變更就會越積越多，下一次要釐清原因也變難。以下各項目，請當成跑這 4 步的候選清單來讀。

flowchart TB
    accTitle: 評估停用的 4 步
    accDescr: 保存變更前的設定，只停用一個項目，量測決定好的指標，沒有效果就改回原樣，這個評估停用 4 步迴圈的圖。
    h1["保存變更前的設定"] --> h2["只停用一個項目"]
    h2 --> h3["量測決定好的指標"]
    h3 -->|"沒有效果就"| h4["改回原樣"]
    h4 -.->|"換下一個候選"| h2

圖 22: 「評估停用」不是叫你停用，而是跑這 4 步並量測。

10.1 一般的桌上型／筆記型電腦

• Speed & Duplex: Auto
• MTU / Jumbo: 1500／停用
• Checksum Offload: 啟用
• LSO: 啟用
• RSC: 啟用
• RSS: 啟用
• Interrupt Moderation: 預設值／Adaptive
• Buffers: 預設值
• Flow Control: 預設值
• EEE / Green Ethernet: 預設值
• Selective Suspend: 預設值
• Wake on LAN: 只在需要時

也就是說，先不要偏離預設值是基本。

10.2 NAS／備份／大量複製

• Speed & Duplex: Auto
• Jumbo: 專用路徑能對齊就評估
• Checksum Offload: 啟用
• LSO: 啟用
• RSC: 啟用
• RSS: 啟用
• RSS queues: 必要時稍微增加
• Receive / Transmit Buffers: 有 drop 就稍微增加
• Interrupt Moderation: 預設值／略微調高
• EEE: 以穩定性為重就評估停用

大量傳輸時，減少封包數、降低 CPU、避免 queue 不足容易發揮效果。

10.3 工業相機／裝置控制／以低延遲為重

• Speed & Duplex: 基本是 Auto。必要時配合對端固定
• Jumbo: 相機／NIC／交換器都對齊就評估
• Checksum Offload: 先啟用
• LSO: 懷疑送出端相容性時就暫時評估停用
• RSC: 以低延遲或觀測為優先就是停用候選
• Interrupt Moderation: 評估 Low／Off
• Buffers: 不要加太多
• Flow Control: 要評估 pause 的副作用
• EEE / Green Ethernet: 停用候選
• Selective Suspend／電源管理: 停用候選

為了 throughput 最佳化的設定，不見得對 low latency 有利。

10.4 Hyper-V 主機

• VMQ / VMMQ / SR-IOV: 依組態評估
• RSS: 對主機端的流量很重要
• RSC: 依 vSwitch 組態會有限制
• QoS / VLAN: 配合 vSwitch 的設計
• Flow Control / PFC: 和儲存／RDMA 的設計一起考量

這不是 desktop tuning，而是虛擬化平台設計。

10.5 排查問題用的暫時設定

釐清缺陷時，先回到單純的世界很有效。

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: 停用
• EEE: 停用
• LSO: 暫時停用
• RSC: 暫時停用
• Interrupt Moderation: 預設值或調低
• Wake / power save: 不需要就停用
• 變更前的設定: 務必保存

釐清原因時，把行為單純化勝過效能最佳化。

11. 依症狀最先鎖定的地方

11.1 應該是 1Gbps／2.5Gbps 卻變成 100Mbps

先看的順序，大致是這樣。

1. 網路線
2. dock／USB NIC／轉接器
3. 交換器側的連接埠
4. 更新驅動程式
5. EEE / Green Ethernet
6. 把 Speed & Duplex 改回 Auto
7. 還是不行，就試著依對端設定固定

一開始就手動固定是最後才做的事。

flowchart TB
    accTitle: 掉到 100Mbps 時的檢查順序
    accDescr: 依照網路線、dock 或 USB NIC、交換器側的連接埠、更新驅動程式、釐清 EEE 的影響、把速度改回 Auto，還是不行才依對端設定固定的順序檢查的圖。
    s1["網路線"] --> s2["dock / USB NIC / 轉接器"]
    s2 --> s3["交換器側的連接埠"]
    s3 --> s4["更新驅動程式"]
    s4 --> s5["釐清 EEE 的影響"]
    s5 --> s6["把 Speed & Duplex 改回 Auto"]
    s6 -->|"還是不行"| s7["依對端設定固定"]

圖 23: 降速的調查從實體層依序往下，手動固定留作最後的手段。

11.2 大量傳輸很慢，但 ping 正常

想看的是這幾項。

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame（如果是專用路徑）
• NIC 統計中的 drop／error

這是 throughput 類的問題，所以 Jumbo、queue、offload 容易發揮效果。

11.3 小型 request/response 的延遲很大、在意 jitter

想檢查的是這 5 項。

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Buffers 是不是給太多了

在這個區塊，合併處理類的最佳化反而可能增加體感延遲。

11.4 睡眠喚醒後 NIC 不見了／有幾秒連不上

以電源相關為主，想看的是這 5 項。

• Selective Suspend
• Device Sleep／Standby 相關設定
• Power Management 索引標籤的 Allow the computer to turn off this device...
• dock／USB NIC 的 firmware
• Wake 設定的組合

喚醒後恢復的問題，比起 NIC 本身，多半出在電源管理。

11.5 封包擷取上出現大量 checksum error

在急著說「線路壞了」之前，先檢查這幾項。

• Checksum Offload 是否啟用
• LSO 是否啟用
• 擷取的位置是在送出之前，還是在 wire 上
• 用別的主機或鏡射埠看時是否也一樣

本機 capture 的 checksum error，真的很常只是 offload 造成的顯示假象。

只針對第三項「擷取的位置是在送出之前，還是在 wire 上」補充一下。在自己的電腦上擷取時，看到的是 NIC 還沒填入 checksum 的封包。 如果 offload 是啟用的，checksum 欄位還是空的或暫定值，解析工具當然會顯示「不正確」。實際流過網路線的封包是正確的，這種情況很常發生。

flowchart TB
    accTitle: 本機擷取看起來像 checksum 錯誤的機制
    accDescr: 在自己的電腦上擷取看到的是 NIC 還沒填入 checksum 的封包，所以 offload 啟用時解析工具會顯示不正確，但實際流過網路線的封包可能是正確的機制的圖。
    lc1["在自己的電腦上擷取"] --> pre1["看到還沒填入 checksum 的封包"]
    pre1 --> bad1["工具顯示不正確"]
    wire1["用鏡射埠看 wire 上"] --> okw1["實際的封包是正確的"]
    okw1 -.-> ver1["兩邊對照就能確定是 offload 的顯示假象"]

圖 24: 本機的擷取位置在 NIC 之前，所以 offload 啟用時的錯誤顯示多半只是顯示上的問題。

用來確認的工具，大致是以下三個。

pktmon 的日誌可以轉換成 pcapng，能直接用 Wireshark 開啟。

pktmon etl2pcap log.etl --out capture.pcapng

如果是「在本機看是 checksum error，在鏡射埠看是正常」，那就確定是 offload 造成的顯示假象。確認到這一步之後再去動設定。

11.6 只有 Hyper-V 的 VM 很慢／CPU 分佈不均

該看的不只是 desktop 那種 RSS。

• VMQ / VMMQ
• SR-IOV
• vSwitch binding
• VLAN / QoS
• 主機端 RSS 與 VM 端 queue 的分工

在虛擬化裡，把是誰在處理 packet 畫成圖比較容易梳理。

12. 用 PowerShell 查看與變更時的實用備忘

12.1 先保存現況

變更前的備份很重要。

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

12.2 查看一覽

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

12.3 查看 RSS / RSC / 統計

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

12.4 變更範例

實際的顯示名稱每張 NIC 都不同，所以先看過一覽再變更。

# 範例：變更 Jumbo Packet（值每張 NIC 都不同）
Set-NetAdapterAdvancedProperty -Name "Ethernet" `
  -DisplayName "Jumbo Packet" `
  -DisplayValue "9014 Bytes"

# 範例：設定 RSS 的接收佇列數
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 4

12.5 Jumbo 的連通確認

# 相當於標準 MTU 1500
ping <對端IP> -f -l 1472

# 相當於 MTU 9000
ping <對端IP> -f -l 8972

1472 與 8972 是扣掉 IP／ICMP header 之後的 payload。驅動程式 UI 上的 9014 Bytes 和這裡 ping 的數字並不一致。

12.6 實務備忘

• 部分設定需要停用／啟用介面卡或重新開機
• DisplayName 有時會被在地化
• 就算是同一家廠商，項目名稱也可能隨 driver version 改變
• 要用 PowerShell 自動化的話，先把實機的值列舉出來再寫比較安全

13. 總結

Windows 的 NIC 詳細設定，只看項目名稱的話每一個都「看起來很強」。 但實際上，這是一個要拿 throughput、latency、CPU、power、compatibility 當中的哪一項，正確答案就會跟著變的世界。

把本文的重點歸納起來是這樣。

• Speed & Duplex 基本是 Auto
• Jumbo 只在 end-to-end 對齊時才用
• Checksum／RSS／LSO／RSC 原則上預設值最強
• Interrupt Moderation 是 throughput 與 latency 的取捨
• Buffers 只給需要的量
• EEE／Selective Suspend／Wake 類講的是 power／resume
• VMQ／SR-IOV 講的是 Hyper-V
• 老舊的 offload 項目不要動

而最重要的是以下三點。

1. 決定想改善什麼
2. 一次只改一個項目
3. 用數字比較變更前後

NIC 設定不是一按就變快的魔法開關。 不過，只要目的對了就相當有效。反過來說，目的一偏掉，就會很直接地產生反效果。

flowchart TB
    accTitle: 最重要的三個套路
    accDescr: 決定想改善什麼、一次只改一個項目、用數字比較變更前後，只要守住這三個套路，在目的正確的前提下 NIC 設定就會相當有效的圖。
    r1["決定想改善什麼"] --> r2["一次只改一個項目"]
    r2 --> r3["用數字比較變更前後"]
    r3 --> eff1["目的對了就相當有效"]
    r1 -.->|"目的一偏掉"| back1["會直接產生反效果"]

圖 25: 守住目的、一項、數字這三個套路就會有效，偏掉就會產生反效果。

14. 參考資料

以下是撰寫本文時作為基礎參考的官方文件與廠商文件。 Windows 與 NIC 驅動程式的用語浮動很多，最後還是要對照自己 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
• 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：速度固定、Jumbo、Interrupt Moderation、EEE、WoL 等，從各 NIC 型號的支援文章確認比較安全

相關文章

共用相同標籤的最新文章。能以相近的主題延伸理解。

相關主題

與本文相近的主題頁面。以本文為起點，可進一步連到相關服務與其他文章。

與本主題相關的服務

本文連結到以下服務頁面，歡迎從最接近的入口查看。

常見問題

整理諮詢這個主題時常見的問題。

Large Send Offload (LSO) 應該停用嗎？

通常應該保持啟用。LSO 是由 NIC 端把大量的 TCP 送出資料切成細小訊框的機制，對送出量大的通訊，在吞吐量與降低 CPU 使用率上都派得上用場。隨手停用反而容易白白吃掉 CPU。值得考慮停用的情況有兩種：一種是懷疑特定應用程式或驅動程式有相容性問題時，暫時關掉看前後差異，用來縮小範圍；另一種是像工業相機或裝置控制那樣，想評估送出端相容性的場合。就算是為了縮小範圍而停用，一旦確認原因在別處，基本上要把設定改回預設值。

Receive Segment Coalescing (RSC) 是什麼？應該停用嗎？

RSC 是在接收端由 NIC 把多個 TCP 區段合併起來的設定，也叫作 Large Receive Offload。它對接收吞吐量與降低 CPU 使用率有效，所以只要以接收為重，基本方針就是啟用。另一方面，在低延遲或以封包為單位的觀測上有時反而不利，封包擷取與時序觀測的解讀也會稍微改變。想把小型 request/response 的延遲壓低，或是在以低延遲、觀測為優先的環境裡，它就成為評估停用的候選。用 Get-NetAdapterRsc 可以查看目前的狀態。

明明應該是 1Gbps 卻只連上 100Mbps 時，要確認什麼？

一開始就手動固定 Speed & Duplex 是最後的手段。檢查順序是先看網路線，接著是 dock／USB NIC／轉接器、交換器側的連接埠、更新驅動程式、釐清 EEE／Green Ethernet 的影響、把 Speed & Duplex 改回 Auto，還是不行才依對端設定固定。因為降速到 100Mbps 或連線中斷，原因多半不在 NIC 設定，而在實體層或對端設備。只有一邊固定、另一邊維持 Auto 的狀態會造成 duplex mismatch，導致速度下降、重送與異常延遲。

Windows 的 NIC 詳細設定，究竟該啟用哪些？

如果是一般的桌上型或筆記型電腦，基本上先不要偏離預設值。Speed & Duplex 維持 Auto，Checksum Offload／LSO／RSC／RSS 原則上啟用或維持預設值，Jumbo Packet 只有在 NIC、對端與中途的交換器都能 end-to-end 對齊時才使用。EEE 與 Selective Suspend 是為了省電的設定，不是讓速度變快的設定。要改動時，鐵則是先決定想改善什麼（吞吐量、延遲、CPU、耗電量），一次只改一個項目，再用數字比較改動前後。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心，在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。