Расширенные настройки NIC в Windows: RSS, LSO, EEE и Wake on LAN

Вкладка [Дополнительно] (Advanced) у NIC в Windows пестрит незнакомыми словами. Jumbo Packet, Large Send Offload, Interrupt Moderation, Receive Side Scaling, Flow Control, Energy Efficient Ethernet. По одним названиям хочется включить всё сразу, но на практике правильный ответ зависит от того, что вы хотите получить в первую очередь.

• Поднять пропускную способность при больших передачах?
• Ужать задержку мелких пакетов?
• Снизить загрузку CPU?
• Стабилизировать выход из сна и Wake on LAN?
• Локализовать несовместимость с драйвером или коммутатором?

Если оставить это неясным и «включить всё подряд», «на всякий случай Jumbo 9014» или «раз медленно — зафиксировать 1 Gbps Full», проблемы возникают совершенно рутинно.

flowchart TB
    accTitle: Если трогать настройки без цели, легко сломать работу
    accDescr: Если неясно, что важнее, и вы на всякий случай включаете всё, Jumbo или фиксируете скорость, проблемы возникают легко; правильный ответ меняется, когда сначала решено, что важнее.
    vague1["Неясно, что важнее"] --> hasty1["Включить всё, Jumbo, зафиксировать скорость"]
    hasty1 --> acc1["Проблемы возникают рутинно"]
    clear1["Сначала решить, что важнее"] -->|"от этого зависит правильный ответ"| pick3["Сужается набор настроек"]

Рис. 1: Если трогать «сильные» настройки без цели, работу легко сломать; если цель ясна, набор параметров сужается.

В этой статье, ориентируясь в основном на проводные Ethernet-адаптеры Windows 10 / 11 и Windows Server, разбираем, как на практике подходить к расширенным настройкам 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. Если скорость падает до 100 Mbps, сразу фиксировать 1.0 Gbps Full Duplex — это последний шаг, не первый.
• Checksum Offload / RSS / LSO / RSC, как правило, включены или остаются в значениях по умолчанию. Если отключить всё подряд «на всякий случай», CPU чаще тратится впустую.
• Jumbo Packet имеет смысл только когда параметр согласован end-to-end. Если выставить 9014 только на своём NIC, а путь между узлами останется на 1500, это ловушка.
• Interrupt Moderation — компромисс между пропускной способностью и задержкой. Более высокое значение разгружает CPU, но задержка растёт.
• Flow Control иногда снижает число отброшенных пакетов, но может и разнести перегрузку по сети.
• EEE / Green Ethernet / Selective Suspend — настройки энергосбережения, а не способ ускорить работу.
• VMQ / SR-IOV предназначены для хостов Hyper-V и не являются волшебной кнопкой ускорения обычного настольного ПК.
• Wake on Pattern Match часто становится причиной непреднамеренного пробуждения, поэтому если нужен просто Wake on LAN, безопаснее ограничиться Magic Packet.
• Устаревшие пункты вроде TCP Chimney Offload сегодня лучше не трогать.

Иными словами, расширенные настройки NIC — это не место, где нужно «включить всё, что выглядит мощным». Это место, где сначала решают, за что вы боретесь — за пропускную способность, задержку, CPU, энергопотребление или совместимость, — и меняют параметры по одному.

flowchart TB
    accTitle: Зачем нужна вкладка расширенных настроек
    accDescr: Расширенные настройки NIC — не место, где включают всё, что выглядит мощным; сначала выбирают ось (пропускная способность, задержка, CPU, энергопотребление, совместимость) и меняют параметры по одному.
    allon1["Включить всё, что выглядит мощным"] -.->|"это не то место"| tab1["Расширенные настройки NIC"]
    dec1["Сначала выбрать ось"] --> one2["Менять по одному"]
    one2 --> tab1

Рис. 3: Вкладкой расширенных настроек пользуются так: сначала выбрать ось, затем менять параметры по одному.

Карта знаний этой статьи

Расширенные настройки NIC в Windows (вкладка Advanced) складываются из множества пунктов — Speed & Duplex, Jumbo Frame, Checksum Offload, LSO/TSO, RSC/LRO, RSS, Interrupt Moderation, Flow Control, EEE, Wake on LAN, Selective Suspend, VMQ/SR-IOV — и все они настраиваются на одной вкладке. Если нужна пропускная способность больших передач, включают Jumbo, LSO, RSC и RSS; если важнее низкая задержка, RSC, Interrupt Moderation и EEE берут как кандидатов на отключение. Односторонняя фиксация Speed & Duplex может дать duplex mismatch, EEE — downshift линка до 100 Mbps. При включённом Checksum Offload локальный захват иногда показывает checksum error; это отделяют проверкой через pktmon или зеркальный порт.

flowchart LR
    accTitle: Карта знаний расширенных настроек NIC в Windows
    accDescr: Рисунок показывает, что пункты расширенных настроек NIC задаются на вкладке Advanced, что рекомендации расходятся для приоритета пропускной способности и низкой задержки, что Speed & Duplex и EEE могут давать downshift и duplex mismatch, и как Checksum Offload выглядит ошибкой checksum при локальном захвате и проверяется через pktmon.
    nic_advanced_properties["доп. свойства NIC (вкладка Advanced)"]
    speed_duplex["Speed & Duplex"]
    duplex_mismatch["несовпадение duplex"]
    link_speed_downshift["снижение скорости линка"]
    jumbo_frame["Jumbo Packet/Jumbo Frames"]
    checksum_offload["Checksum Offload"]
    local_capture_checksum_error["ложная ошибка checksum при локальном захвате"]
    pktmon["Packet Monitor (pktmon)"]
    lso_tso["Large Send Offload (LSO/TSO)"]
    rsc_lro["RSC/LRO (Receive Segment Coalescing)"]
    rss_nic["RSS (Receive Side Scaling)"]
    interrupt_moderation["Interrupt Moderation"]
    flow_control_8023x["Flow Control (pause-кадр 802.3x)"]
    eee["Energy Efficient Ethernet (EEE / Green Ethernet)"]
    wake_on_lan["Wake on LAN (Wake on Magic Packet)"]
    selective_suspend["Selective Suspend"]
    vmq_sriov["VMQ/VMMQ/SR-IOV"]
    low_latency_workload["нагрузка с упором на низкую задержку"]
    large_transfer_workload["нагрузка с упором на пропускную способность"]
    hyper_v_host_networking["сетевая конфигурация хоста Hyper-V"]
    nic_resume_failure["сбой NIC после выхода из сна"]
    speed_duplex -->|"настраивается"| nic_advanced_properties
    speed_duplex -.->|"может вызвать"| duplex_mismatch
    speed_duplex -.->|"снижает"| link_speed_downshift
    jumbo_frame -->|"настраивается"| nic_advanced_properties
    checksum_offload -->|"настраивается"| nic_advanced_properties
    checksum_offload -.->|"может вызвать"| local_capture_checksum_error
    local_capture_checksum_error -->|"проверяется"| pktmon
    lso_tso -->|"настраивается"| nic_advanced_properties
    rsc_lro -->|"настраивается"| nic_advanced_properties
    rss_nic -->|"настраивается"| nic_advanced_properties
    interrupt_moderation -->|"настраивается"| nic_advanced_properties
    flow_control_8023x -->|"настраивается"| nic_advanced_properties
    eee -->|"настраивается"| nic_advanced_properties
    wake_on_lan -->|"настраивается"| nic_advanced_properties
    selective_suspend -->|"настраивается"| nic_advanced_properties
    vmq_sriov -->|"настраивается"| nic_advanced_properties
    rsc_lro -.->|"не рекомендуется"| low_latency_workload
    interrupt_moderation -.->|"не рекомендуется"| low_latency_workload
    eee -.->|"не рекомендуется"| low_latency_workload
    jumbo_frame -.->|"рекомендуется для"| large_transfer_workload
    rss_nic -->|"рекомендуется для"| large_transfer_workload
    lso_tso -->|"рекомендуется для"| large_transfer_workload
    rsc_lro -->|"рекомендуется для"| large_transfer_workload
    vmq_sriov -->|"рекомендуется для"| hyper_v_host_networking
    selective_suspend -.->|"может вызвать"| nic_resume_failure
    eee -.->|"может вызвать"| link_speed_downshift

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 26, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Где смотреть настройки

2.1 Через графический интерфейс

Через «Сетевые подключения»

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
• Иногда обрывается / становится 100 Mbps → кабель, оборудование на другом конце, Speed & Duplex, EEE, драйвер

Если трогать одни и те же настройки при разных целях, вместо улучшения легко получить ухудшение.

flowchart TB
    accTitle: Сначала разделить, что именно «медленно»
    accDescr: За одной жалобой «сеть медленная» скрываются разные проблемы; если не решить, что улучшить, и не трогать только подходящую группу настроек, вместо улучшения легко получить ухудшение.
    slow1["Сеть медленная"] --> split1["Сначала разделить содержимое"]
    split1 --> aim1["Трогать только настройки под цель"]
    slow1 -.->|"трогать, не разделяя"| worse1["Вместо улучшения — ухудшение"]

Рис. 5: Если не разделить симптом, одно и то же «медленно» даёт обратный эффект.

3.2 Сначала подозревать физический уровень и оборудование на другом конце

Есть проблемы, которые настройками NIC не лечатся — это обычное дело.

• Неисправный кабель
• Несовместимость с коммутатором / маршрутизатором / док-станцией
• Старая прошивка
• Недостаток питания у USB NIC
• Ошибки на стороне порта
• Потери пакетов и повторные передачи

Особенно при падении до 100 Mbps, флаппинге линка и поломке только на больших передачах быстрее сначала проверить физику и оборудование на другом конце, а не настройки.

flowchart TB
    accTitle: Сначала физический уровень и оборудование на другом конце
    accDescr: При падении до 100 Mbps, флапе линка или поломке только на больших передачах быстрее сначала проверить кабель и оборудование на другом конце, а не настройки NIC.
    symp1["Симптомы вроде downshift и флаппинга"] --> phys1["Сначала кабель, сосед и физический уровень"]
    phys1 -->|"если осталось"| nicw1["Изоляция настроек NIC"]
    phys1 -.-> nofix1["Есть проблемы, которые настройки не лечат"]

Рис. 6: Симптомы линка быстрее проверять с физического уровня и оборудования на другом конце, а не с настроек.

3.3 Менять по одному параметру за раз

Если разом изменить Jumbo, LSO, RSC, RSS и EEE, вы не поймёте, что именно сработало. Базовое правило — записать настройки до изменения, менять их по одному пункту и измерять изменения.

3.4 Решить, что измерять

Как минимум стоит смотреть следующее.

• Скорость линка (1G / 2.5G / 10G и т. д.)
• Пропускная способность
• Задержка
• Загрузка CPU
• Статистика NIC (drop / error / нехватка буфера)
• Стабильность выхода из сна

Изменения настроек убедительнее оценивать не «на ощупь», а по цифрам.

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. «Раз не выходит 1 Gbps — зафиксируем 1 Gbps 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
• ОС и утилиты могут смотреть на это с точки зрения L3, например MTU 9000
• Коммутатор может считать с учётом CRC и VLAN-тега

Если сравнивать эти числа просто «в лоб», попасться — совершенно обычное дело.

flowchart TB
    accTitle: Разные способы считать цифры Jumbo
    accDescr: При одной и той же настройке Jumbo драйвер может показывать размер кадра, ОС и утилиты — MTU с точки зрения L3, а коммутатор — с учётом CRC и VLAN-тега; сравнивать эти числа в лоб опасно.
    drv1["Драйвер: размер кадра"] --> cmp2["Одно и то же считают по-разному"]
    osv1["ОС и утилиты: MTU с точки зрения L3"] --> cmp2
    sw1["Коммутатор: с тегом и CRC"] --> cmp2
    cmp2 --> trap1["Сравнение цифр в лоб даёт ловушку"]

Рис. 9: Драйвер, ОС и коммутатор считают по-разному, поэтому цифры Jumbo не сравнивают в лоб.

Что меняется при изменении

Увеличить / включить

• При передаче больших данных меньше пакетов
• Меньше обработок заголовков
• CPU обычно снижается
• В то же время время занятости канала одним пакетом растёт
• Если где-то на пути настройка не поддерживается, это приводит к drop или фрагментации

Вернуть к стандарту / отключить

• Совместимость максимальна
• Пакетов больше
• На больших передачах обычно растут CPU и накладные расходы на заголовки

Базовая политика на практике

Jumbo имеет смысл только когда согласован end-to-end:

• ваш NIC
• NIC на другом конце
• коммутаторы на пути
• накладные расходы VLAN или виртуальных коммутаторов, если они есть на пути

Если хоть один из этих элементов остаётся на 1500, эффекта не будет — более того, это станет источником сбоев.

flowchart TB
    accTitle: Jumbo имеет смысл только когда согласован end-to-end
    accDescr: Jumbo Frame имеет смысл только когда согласованы ваш NIC, промежуточные коммутаторы и NIC на другом конце; если хоть один остаётся на 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
• Оценивать изменение стоит только при проблемах с качеством линка с конкретным старым оборудованием
• Пока нет указаний производителя, не рассматривайте её как рычаг настройки производительности

5.4 Wait for Link и другие настройки состояния линка

Настройки вроде Wait for Link определяют, ждёт ли драйвер успешного завершения auto negotiation, прежде чем сообщить состояние линка. Log Link State Event — диагностическая настройка, которая пишет события link up/down в журнал событий.

Базовая политика

• На обычном ПК можно оставить значения по умолчанию
• Эти настройки важнее не для самой производительности, а для того, как состояние выглядит при загрузке, и для диагностики failover
• Не тот пункт, который стоит трогать в первую очередь

6. Настройки, которые влияют на CPU, пропускную способность и задержку

Это полоса, которая выглядит самой «многообещающей». Она действительно часто влияет на результат, но направление эффекта чётко расходится.

flowchart TB
    accTitle: У этой полосы настроек направления эффекта расходятся
    accDescr: Настройки, которые влияют на нагрузку CPU, пропускную способность и задержку, расходятся на направление «обрабатывать пакетами» (выгоднее throughput и CPU) и направление «обрабатывать мельче» (выгоднее задержка).
    band1["Полоса настроек, которая выглядит многообещающей"] --> dir1["Обрабатывать пакетами"]
    band1 --> dir2["Обрабатывать мельче"]
    dir1 -.-> g1["Выгоднее throughput и CPU"]
    dir2 -.-> g2["Выгоднее задержка"]

Рис. 11: Даже в одной полосе настроек направления «в сторону throughput» и «в сторону задержки» расходятся.

6.1 Checksum Offload

Настройка, которая переносит расчёт контрольных сумм IP / TCP / UDP на NIC.

Базовая политика

• Как правило включено
• Оставляйте включённым, если хотите снизить нагрузку на CPU
• checksum error в захвате часто — просто то, как выглядит offload
• Временное отключение для изоляции совместимости допустимо

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

Настройка, при которой большие TCP-отправки NIC сам режет на мелкие кадры.

На что влияет

• send-heavy throughput
• снижение загрузки CPU
• крупные непрерывные передачи

Базовая политика

• Обычно включено
• При подозрении на несовместимость конкретного приложения или драйвера временно отключите и сравните разницу

6.3 Receive Segment Coalescing (RSC) / Large Receive Offload

Настройка, которая на приёме собирает несколько TCP-сегментов вместе.

На что влияет

• throughput на приёме
• снижение загрузки CPU

На что обратить внимание

• Может быть невыгодной для низкой задержки или наблюдения на уровне отдельных пакетов
• Немного меняет интерпретацию захвата и замеров времени

Базовая политика

• Если хотите throughput приёма — включено
• Если смотрите latency мелких request/response — кандидат на оценку

flowchart TB
    accTitle: Как работает RSC и где проходит граница оценки
    accDescr: RSC собирает несколько принятых TCP-сегментов на стороне NIC и помогает throughput приёма и снижению CPU; при приоритете низкой задержки или наблюдения на уровне пакетов может мешать и становится кандидатом на оценку.
    seg1["Несколько принятых TCP-сегментов"] --> coal1["NIC собирает их вместе (RSC)"]
    coal1 --> up1["Помогает throughput приёма и CPU"]
    coal1 -.->|"если важнее низкая задержка и наблюдение"| dn1["Может мешать — кандидат на оценку"]

Рис. 12: RSC собирает приём в более крупные порции; если важнее задержка, это кандидат на оценку.

6.4 Более новые UDP-offload (USO / URO)

На современных NIC и в новых версиях ОС для отправки и приёма UDP тоже могут появляться более новые offload-настройки.

Базовая политика

• Даже если такие пункты есть, для начала не уходите от значений по умолчанию
• Измеряйте эффект только когда драйвер достаточно новый, а целевая нагрузка ясно определена
• При устранении неполадок не трогайте их без крайней необходимости

6.5 Receive Side Scaling (RSS)

Настройка, которая распределяет обработку приёма по нескольким CPU. В multi-core среде она весьма важна.

Базовая политика

• На multi-core по умолчанию включено
• В первую очередь проверяйте её при симптоме «нагрузка сидит на одном CPU»
• Она часто выходит на первый план и перед Hyper-V, и перед задачами с высокой пропускной способностью

flowchart TB
    accTitle: Как RSS меняет обработку приёма
    accDescr: Если RSS выключен, обработка приёма садится на один CPU и легче образует затор; если включён, нагрузка распределяется по нескольким CPU и на multi-core чаще растёт throughput.
    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 или перекос очередей
• Бездумное увеличение до максимума может повысить нагрузку от прерываний и 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: Более высокие значения или Adaptive разгружают CPU, но задержка чаще растёт; более низкие или Off снижают задержку, но нагрузка 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

Настройка, которая меняет глубину кольца / буфера.

На что влияет

• устойчивость к всплескам
• sustained throughput
• предотвращение drop

Побочные эффекты

• растёт расход памяти
• более глубокая очередь может увеличить задержку ожидания в очереди

Базовая политика

• Увеличивайте только тогда, когда видны drop или buffer shortage
• Избегайте выставления максимума «на всякий случай»

flowchart TB
    accTitle: Когда увеличивать глубину буфера
    accDescr: Более глубокий буфер помогает устойчивости к всплескам и снижению drop, но увеличивает расход памяти и задержку в очереди; увеличивать стоит только когда drop или buffer shortage уже видны.
    obs1["Видны drop или buffer shortage"] -->|"только когда видны"| inc1["Увеличить буфер"]
    inc1 -.-> side1["Могут вырасти расход памяти и задержка в очереди"]
    non1["Максимум «на всякий случай»"] -.->|"избегать"| inc1

Рис. 15: Буфер увеличивают, когда симптом уже виден в цифрах; максимум «на всякий случай» не ставят.

6.9 Flow Control

Настройка, связанная с отправкой и приёмом pause-кадров 802.3x.

Базовая политика

• Кандидат, если нужно снизить drop
• Однако pause иногда разносит перегрузку в другое место сети
• В системах с низкой задержкой подходите к ней осторожно
• Рассматривайте вместе с проектом сети в целом

flowchart TB
    accTitle: Две стороны Flow Control
    accDescr: Pause-кадры Flow Control иногда снижают drop, но иногда разносят перегрузку в другое место, поэтому решение принимают вместе с проектом сети в целом.
    fc1["pause-кадр (Flow Control)"] -->|"иногда помогает"| less1["Снижает drop"]
    fc1 -.->|"иногда разносит"| cong1["Другая перегрузка"]
    fc1 --> tot1["Решение вместе с проектом сети в целом"]

Рис. 16: Flow Control снижает drop, но может разнести перегрузку; по одному параметру его не судят.

7. Настройки VLAN, QoS и виртуализации

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

Полоса, которая отвечает за VLAN 802.1Q и приоритеты 802.1p.

Базовая политика

• Обращайте на неё внимание только когда VLAN / QoS действительно используются
• В простой конфигурации access-порта можно оставить значения по умолчанию
• Конфигурация, где теги появляются сами собой, усложняет диагностику — будьте внимательны

7.2 VMQ / VMMQ / SR-IOV

Эта настройка приобретает смысл только на хостах Hyper-V и платформах виртуализации.

Базовая политика

• Не рассматривайте её как обычную настройку тюнинга десктопа
• На хосте Hyper-V оценивайте её вместе с конфигурацией vSwitch, распределением очередей и настройками на стороне гостя
• Глядя только на одну сторону, правильный ответ найти трудно

flowchart TB
    accTitle: Единица оценки VMQ / SR-IOV
    accDescr: VMQ и SR-IOV имеют смысл на хосте Hyper-V и платформе виртуализации; их оценивают вместе с конфигурацией vSwitch, распределением очередей и настройками гостя, а не по одной стороне.
    vm1["VMQ / VMMQ / SR-IOV"] --> hv1["Смысл появляется на хосте Hyper-V"]
    hv1 --> setb["Оценивать вместе с vSwitch, очередями и гостем"]
    vm1 -.->|"не рассматривать"| dt1["Обычный тюнинг десктопа"]

Рис. 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.

Как на неё смотреть

• Это не настройка ускорения
• Она влияет на энергопотребление
• В зависимости от оборудования на другом конце и состояния кабеля она становится кандидатом на изоляцию при нестабильности линка или переходе на 100 Mbps

Базовая политика

• Для общего использования можно оставить значения по умолчанию
• При нестабильности линка, переходе на 100 Mbps или приоритете низкой задержки — в первую очередь кандидат на отключение при изоляции

flowchart TB
    accTitle: Место EEE среди настроек
    accDescr: EEE — настройка энергосбережения, которая снижает потребление линка в idle, а не скорость; в зависимости от оборудования на другом конце и кабеля она становится кандидатом на изоляцию нестабильности линка и downshift до 100 Mbps.
    eee1["EEE / Green Ethernet"] --> sv3["Снижает потребление в idle"]
    eee1 -.->|"это не настройка ускорения"| spd1["Скорость и производительность"]
    eee1 -.->|"в зависимости от соседа и кабеля"| tgl1["Кандидат на изоляцию нестабильности линка и downshift"]

Рис. 18: EEE — настройка энергосбережения; при нестабильности линка или переходе на 100 Mbps её в первую очередь берут в изоляцию.

8.2 Selective Suspend / Device Sleep / управление линком в режиме ожидания

Проще говоря, это настройка того, насколько глубоко NIC разрешено «засыпать» в idle или во сне системы.

Базовая политика

• На ноутбуках начинайте со значений по умолчанию
• При проблемах с выходом из сна подозревайте её в первую очередь
• На управляющих оборудованием ПК и при работе 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 срабатывает только когда согласованы настройка Magic Packet на NIC, сторона BIOS/UEFI и вкладка Power Management; все три места нужно проверить вместе.
    m1["Настройка Magic Packet на NIC"] --> 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 вообще не нужен, все настройки пробуждения можно отключить

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

Довольно старая настройка. В современном коммутируемом полнодуплексном Ethernet она не играет главной роли.

Базовая политика

• В современной обычной локальной сети оставляйте значение по умолчанию
• Трогайте только при наличии указаний производителя для старого оборудования или особых условий

9.3 Header Data Split

Настройка, в основном для серверов, которая помогает обработке CPU за счёт раздельной работы с заголовком пакета и полезной нагрузкой.

Базовая политика

• Для серверов / для конкретных нагрузок
• На обычных клиентских машинах оставляйте значение по умолчанию

9.4 Low Latency Interrupts

У некоторых производителей встречается пункт вроде Low Latency Interrupts.

Базовая политика

• Используйте только тогда, когда измерения подтверждают выигрыш
• Не та настройка, которую включают «по ощущениям»

9.5 Устаревшие пункты вроде TCP Chimney Offload / IPsec Task Offload

На старых NIC и драйверах такие пункты иногда встречаются.

Базовая политика

• Правильный ответ сегодня — не трогать, не использовать
• Не следуйте за старой документацией или соображениями совместимости из прошлого

flowchart TB
    accTitle: Общий подход к пунктам главы 9
    accDescr: Перезапись MAC-адреса, старые настройки, серверные пункты и устаревшие offload обычно оставляют по умолчанию и трогают только при указании производителя, явных требованиях и измерениях.
    rare1["Пункты главы 9"] --> keep1["Обычно не трогать, оставлять по умолчанию"]
    keep1 -->|"трогать, только если"| cond1["Есть указание производителя или явное требование"]
    cond1 -.-> meas1["Использовать, только когда измерение подтверждает выигрыш"]

Рис. 21: Полоса, которую обычно не трогают, даже если пункт виден; руки туда только при явном указании, требовании и измерении.

10. Ориентиры по целям

Ниже много раз встречаются формулировки «оценка отключения» и «кандидат на отключение». Это не «отключите», а возьмите в оценку. Содержимое — те же принципы 3.3 и 3.4, конкретно эти четыре шага.

1. Сохранить настройки до изменения (Export-Csv из 12.1)
2. Отключить только один пункт (3.3)
3. Измерить показатели из 3.4 (пропускная способность, задержка, CPU, статистика NIC, стабильность выхода из сна)
4. Если эффекта нет — вернуть как было

Если шаг 4 пропускают, бессмысленные изменения копятся, и следующий разбор становится труднее. Каждый пункт ниже читайте как список кандидатов, по которым прогоняют эти четыре шага.

flowchart TB
    accTitle: Четыре шага оценки отключения
    accDescr: Цикл оценки отключения: сохранить настройки до изменения, отключить один пункт, измерить выбранные показатели и при отсутствии эффекта вернуть как было.
    h1["Сохранить настройки до изменения"] --> h2["Отключить только один пункт"]
    h2 --> h3["Измерить выбранные показатели"]
    h3 -->|"если эффекта нет"| h4["Вернуть как было"]
    h4 -.->|"к следующему кандидату"| h2

Рис. 22: «Оценка отключения» — не «отключите», а прогон этих четырёх шагов с измерением.

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 и предотвращение нехватки очередей.

10.3 Промышленные камеры / управление оборудованием / приоритет низкой задержки

• Speed & Duplex: по умолчанию Auto; при необходимости зафиксировать в соответствии с оборудованием на другом конце
• Jumbo: оценить, если согласованы камера / NIC / коммутатор
• Checksum Offload: сначала включить
• LSO: временно оценить отключение, если подозреваете несовместимость на отправке
• RSC: кандидат на отключение, если приоритет — низкая задержка или наблюдение
• Interrupt Moderation: оценить Low / Off
• Buffers: не увеличивать чрезмерно
• Flow Control: нужна оценка побочных эффектов pause-кадров
• EEE / Green Ethernet: кандидат на отключение
• Selective Suspend / управление питанием: кандидат на отключение

Настройки, оптимизированные под пропускную способность, не всегда выгодны для низкой задержки.

10.4 Хосты Hyper-V

• VMQ / VMMQ / SR-IOV: оценивать в зависимости от конфигурации
• RSS: важен для трафика на стороне хоста
• RSC: ограничен конфигурацией vSwitch
• QoS / VLAN: согласовывать с проектированием vSwitch
• Flow Control / PFC: рассматривать вместе с проектированием хранилища / RDMA

Это не настройка десктопа, а проектирование платформы виртуализации.

10.5 Временные настройки для устранения неполадок

При изоляции дефекта эффективно временно вернуться к простому базовому состоянию.

• Speed & Duplex: Auto
• MTU: 1500
• Jumbo: отключено
• EEE: отключено
• LSO: временно отключено
• RSC: временно отключено
• Interrupt Moderation: значение по умолчанию или ниже
• Wake / энергосбережение: отключено, если не нужно
• Настройки до изменения: обязательно сохранить

При изоляции проблемы упрощение поведения важнее оптимизации производительности.

11. С чего начать проверку по типу симптома

11.1 Должно быть 1 Gbps / 2.5 Gbps, а получается 100 Mbps

Порядок проверки примерно такой.

1. Кабель
2. Док-станция / USB NIC / переходник
3. Порт на стороне коммутатора
4. Обновление драйвера
5. EEE / Green Ethernet
6. Возврат Speed & Duplex к Auto
7. Если ничего не помогло — попробовать фиксацию, согласованную с оборудованием на другом конце

Сразу переходить к ручной фиксации — это последний шаг, а не первый.

flowchart TB
    accTitle: Порядок проверки при падении до 100 Mbps
    accDescr: Порядок такой: кабель, док-станция или USB NIC, порт коммутатора, обновление драйвера, изоляция EEE, возврат к Auto Negotiation и только если ничего не помогло — фиксация, согласованная с оборудованием на другом конце.
    s1["Кабель"] --> s2["Док-станция / USB NIC / переходник"]
    s2 --> s3["Порт на стороне коммутатора"]
    s3 --> s4["Обновление драйвера"]
    s4 --> s5["Изоляция EEE"]
    s5 --> s6["Speed & Duplex вернуть в Auto"]
    s6 -->|"если ничего не помогло"| s7["Фиксация, согласованная с другим концом"]

Рис. 23: Расследование downshift идут от физики; ручная фиксация — крайняя мера.

11.2 Большие передачи медленные, но ping в норме

Стоит проверить следующее.

• Checksum Offload
• LSO
• RSC
• RSS
• Receive / Transmit Buffers
• Jumbo Frame (если путь выделенный)
• drop / error в статистике NIC

Это проблема класса throughput, поэтому обычно помогают Jumbo, настройка очередей и offload.

11.3 Большая задержка мелких request/response, беспокоит jitter

Стоит проверить следующие пять пунктов.

• Interrupt Moderation
• RSC
• EEE
• Flow Control
• Не завышены ли буферы

В этой области оптимизации, ориентированные на пакетную обработку, могут, наоборот, увеличить ощутимую задержку.

11.4 После выхода из сна NIC исчезает / несколько секунд нет связи

В первую очередь, с фокусом на электропитание, стоит проверить эти пять пунктов.

• Selective Suspend
• Настройки, связанные с Device Sleep / Standby
• Allow the computer to turn off this device... на вкладке Power Management
• Прошивка док-станции / USB NIC
• Комбинация настроек пробуждения

Проблемы с выходом из сна чаще связаны с управлением электропитанием, чем с самим NIC.

11.5 В захвате пакетов видно множество ошибок контрольной суммы

Прежде чем поспешно заявлять «линия сломана», проверьте следующее.

• Включён ли Checksum Offload
• Включён ли LSO
• Захват выполнен до отправки или уже на канале
• Совпадает ли картина при просмотре с другого хоста или через зеркальный порт

Ошибки контрольной суммы в локальном захвате действительно очень часто — это просто то, как выглядит offload.

Третий пункт — «захват выполнен до отправки или уже на канале» — стоит пояснить отдельно. Если захватывать на своём ПК, видны пакеты до того, как NIC заполнит checksum. При включённом offload поле checksum ещё пустое или содержит временное значение, поэтому анализатор закономерно показывает «неверно». На деле пакеты, которые уже пошли по кабелю, часто корректны.

flowchart TB
    accTitle: Почему локальный захват показывает checksum error
    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 работают медленно / перекос по CPU

Смотреть нужно не только на «десктопный» RSS.

• VMQ / VMMQ
• SR-IOV
• привязка vSwitch
• VLAN / QoS
• разделение работы между RSS на стороне хоста и очередями на стороне VM

В виртуализации проще разобраться, если изобразить схематично, кто именно обрабатывает пакеты.

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. Эти числа в ping не совпадают с 9014 Bytes, которые показывает интерфейс драйвера.

12.6 Практические заметки

• Для части настроек требуется отключение/включение адаптера или перезагрузка
• DisplayName иногда бывает локализован
• Даже у одного производителя названия пунктов могут меняться в зависимости от версии драйвера
• Если автоматизируете через PowerShell, безопаснее сначала перечислить значения на реальной машине, а уже потом писать скрипт

13. Итог

Если смотреть только на названия пунктов, все расширенные настройки NIC в Windows выглядят «мощно». Но на деле это мир, где правильный ответ зависит от того, за что вы боретесь — throughput, latency, CPU, power или compatibility.

Ключевые моменты этой статьи:

• Speed & Duplex по умолчанию — Auto
• Jumbo — только когда согласован end-to-end
• Checksum / RSS / LSO / RSC: как правило, сильнее всего значения по умолчанию
• Interrupt Moderation — компромисс между пропускной способностью и задержкой
• Buffers — увеличивать ровно настолько, насколько нужно
• EEE / Selective Suspend / настройки Wake — это вопрос энергопотребления и выхода из сна
• 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 — механизм, при котором большие TCP-отправки NIC сам режет на мелкие кадры; он помогает пропускной способности при интенсивной передаче и снижает загрузку CPU. Если отключить его «на всякий случай», CPU чаще начинает тратиться впустую. Отключение имеет смысл либо как временный шаг изоляции — выключить, сравнить разницу, если подозреваете несовместимость конкретного приложения или драйвера, — либо когда нужно оценить совместимость передачи, например для промышленных камер или управления оборудованием. Даже если вы отключили параметр при разборе, базовое правило — вернуть значение по умолчанию, как только выяснится, что причина в другом.

Что такое Receive Segment Coalescing (RSC)? Стоит ли его отключать?

RSC — настройка, при которой несколько принятых TCP-сегментов NIC собирает вместе; её также называют Large Receive Offload. Она помогает пропускной способности приёма и снижению загрузки CPU, поэтому если важен приём, базовая политика — оставлять её включённой. С другой стороны, она может мешать низкой задержке и наблюдению на уровне отдельных пакетов, а интерпретация захвата и замеров времени немного меняется. Если нужно ужать задержку мелких request/response или в среде, где важнее низкая задержка и наблюдение, отключение становится кандидатом на оценку. Текущее состояние смотрите командой Get-NetAdapterRsc.

Должно быть 1 Gbps, а линк встаёт на 100 Mbps — что проверить?

Сразу фиксировать Speed & Duplex вручную — крайняя мера. Порядок такой: сначала кабель, затем док-станция / USB NIC / переходник, порт на стороне коммутатора, обновление драйвера, изоляция EEE / Green Ethernet, возврат Speed & Duplex к Auto и только если ничего не помогло — фиксация, согласованная с оборудованием на другом конце. Переход на 100 Mbps и обрывы линка чаще связаны с физическим уровнем и оборудованием на другом конце, а не с настройками NIC. Состояние «одна сторона зафиксирована, другая на Auto» даёт duplex mismatch и приводит к падению скорости, повторным передачам и аномальным задержкам.

Какие расширенные настройки NIC в Windows в итоге стоит включать?

Для обычного настольного ПК или ноутбука базовое правило — сначала не уходить от значений по умолчанию. Speed & Duplex — Auto; Checksum Offload / LSO / RSC / RSS — как правило включены или на значениях по умолчанию; Jumbo Packet используйте только тогда, когда NIC, оборудование на другом конце и промежуточные коммутаторы согласованы end-to-end. EEE и Selective Suspend — настройки энергосбережения, а не способ ускорить работу. При изменениях железное правило: сначала решить, что именно вы хотите улучшить (пропускную способность, задержку, CPU, энергопотребление), затем менять только один параметр за раз и сравнивать результат до и после по цифрам.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.