Высокий пинг в игре? Лезем в настройки сетевой карты. Часть 2

Продолжение статьи о тонкой настройке сетевого стека Windows-систем

Привет. Это – вторая часть статьи. Поэтому всё, что относится к первой, относится и к этой. В этой, правда, будет больше настроек сетевых адаптеров, но не суть. Не буду повторяться, разве что в плане диспозиции.

Диспозиция

Я предполагаю, что Вы, товарищ читатель, знаете на приемлемом уровне протокол TCP, да и вообще протоколы сетевого и транспортного уровней. Ну и канального тоже. Чем лучше знаете – тем больше КПД будет от прочтения данной статьи. Речь будет идти про настройку для ядра NT 6.1 (Windows 7 и Windows Server 2008 R2). Всякие исторические ссылки будут, но сами настройки и команды будут применимы к указанным ОС, если явно не указано иное. В тексте будут упоминаться ключи реестра. Некоторые из упоминаемых ключей будут отсутствовать в официальной документации. Это не страшно, но перед любой серьёзной модификацией рабочей системы лучше фиксировать то, что Вы с ней делаете, и всегда иметь возможность удалённого доступа, не зависящую от состояния сетевого интерфейса (например KVM).

Содержание (то, что зачёркнуто, было в первой части статьи)

Работаем с RSSРаботаем с CTCPРаботаем с NetDMAРаботаем с DCAРаботаем с ECNРаботаем с TCP TimestampsРаботаем с WSHРаботаем с MPP

• Работаем с управлением RWND (autotuninglevel)
• Работаем с Checksum offload IPv4/IPv6/UDP/TCP
• Работаем с Flow Control
• Работаем с Jumbo Frame
• Работаем с AIFS (Adaptive Inter-frame Spacing)
• Работаем с Header Data Split
• Работаем с Dead Gateway Detection

Работаем с управлением RWND (autotuninglevel)

Данный параметр тесно связан с описаным ранее параметром WSH – Window Scale Heuristic. Говоря проще, включение WSH – это автоматическая установка данного параметра, а если хотите поставить его вручную – выключайте WSH.

Параметр определяет логику управление размером окна приёма – rwnd – для TCP-соединений. Если Вы вспомните, то размер этого окна указывается в поле заголовка TCP, которое называется window size и имеет размер 16 бит, что ограничивает окно 2^16 байтами (65536). Этого может быть мало для текущих высокоскоростных соединений (в сценариях вида “с одного сервера по IPv6 TCPv6-сессии и десятигигабитной сети копируем виртуалку” – совсем тоскливо), поэтому придуман RFC 1323, где описывается обходной способ. Почему мало? Потому что настройка этого окна по умолчанию такова:

• Для сетей со скоростью менее 1 мегабита – 8 КБ (если точнее, 6 раз по стандартному MSS – 1460 байт)
• Для сетей со скоростью 100 Мбит и менее, но более 1 Мбит – 17 КБ (12 раз по стандартному MSS – 1460 байт)
• Для сетей со скоростью выше 100 Мбит – 64 КБ (максимальное значение без поддержки RFC 1323)

Способ обхода, предлагаемый в RFC 1323, прост и красив. Два хоста, ставящих TCP-сессию, согласовывают друг с другом параметр, который является количеством бит, на которые будет сдвинуто значение поля windows size. То есть, если они согласуют этот параметр равный 2, то оба из них будут читать это поле сдвинутым “влево” на 2 бита, что даст увеличение параметра в 2^2=4 раза. И, допустим, значение этого поля в 64К превратится в 256К. Если согласуют 5 – то поле будет сдвинуто “влево” на 5 бит, и 64К превратится в 2МБ. Максимальный поддерживаемый Windows порог этого значения (scaling) – 14, что даёт максимальный размер окна в 1ГБ.

Как настраивается RWND в Windows

Существующие варианты настройки этого параметра таковы:

• netsh int tcp set global autotuninglevel=disabled – фиксируем значение по умолчанию (для гигабитного линка это будет 64K), множитель – нуль. Это поможет, если промежуточные узлы (например, старое сетевое оборудование) не понимает, что значение окна TCP – это не поле window size, а оно, модифицированное с учётом множителя scaling.
• netsh int tcp set global autotuninglevel=normal – оставляем автонастройку, значение множителя – не более 8.
• netsh int tcp set global autotuninglevel=highlyrestricted – оставляем автонастройку, значение множителя – не более 2.
• netsh int tcp set global autotuninglevel=restricted – оставляем автонастройку, значение множителя – не более 4.
• netsh int tcp set global autotuninglevel=experimental – оставляем автонастройку, значение множителя – до 14.

Ещё раз – если Вы включите WSH, он сам будет подбирать “максимальный” множитель, на котором достигается оптимальное качество соединения. Подумайте перед тем, как править этот параметр вручную.

Работаем с Checksum offload IPv4/IPv6/UDP/TCP

Данная пачка технологий крайне проста. Эти настройки снимают с CPU задачи проверки целостности полученых данных, которые (задачи, а не данные) являются крайне затратными. То есть, если Вы получили UDP-датаграмму, Вам, по сути, надо проверить CRC у ethernet-кадра, у IP-пакета, и у UDP-датаграммы. Всё это будет сопровождаться последовательным чтением данных из оперативной памяти. Если скорость интерфейса большая и трафика много – ну, Вы понимаете, что эти, казалось бы, простейшие операции, просто будут занимать ощутимое время у достаточно ценного CPU, плюс гонять данные по шине. Поэтому разгрузки чексумм – самые простые и эффективно влияющие на производительность технологии. Чуть подробнее про каждую из них:

IPv4 checksum offload

Сетевой адаптер самостоятельно считает контрольную сумму у принятого IPv4 пакета, и, в случае, если она не сходится, дропит пакет.

Бывает продвинутая версия этой технологии, когда адаптер умеет сам проставлять чексумму отправляемого пакета. Тогда ОС должна знать про поддержку этой технологии, и ставить в поле контрольной суммы нуль, показывая этим, чтобы адаптер выставлял параметр сам. В случае chimney, это делается автоматически. В других – зависит от сетевого адаптера и драйвера.

IPv6 checksum offload

Учитывая, что в заголовке IPv6 нет поля checksum, под данной технологией обычно имеется в виду “считать чексумму у субпротоколов IPv6, например, у ICMPv6”. У IPv4 это тоже подразумевается, если что, только у IPv4 субпротоколов, подпадающих под это, два – ICMP и IGMP.

UDPv4/v6 checksum offload

Реализуется раздельно для приёма и передачи (Tx и Rx), соответственно, считает чексуммы для UDP-датаграмм.

TCPv4/v6 checksum offload

Реализуется раздельно для приёма и передачи (Tx и Rx), соответственно, считает чексуммы для TCP-сегментов. Есть тонкость – в TCPv6 чексумма считается по иной логике, нежели в UDP.

Общие сведения для всех технологий этого семейства

Помните, что все они, по сути, делятся на 2 части – обработка на адаптере принимаемых данных (легко и не требует взаимодействия с ОС) и обработка адаптером отправляемых данных (труднее и требует уведомления ОС – чтобы ОС сама не считала то, что будет посчитано после). Внимательно изучайте документацию к сетевым адаптерам, возможности их драйверов и возможности ОС.

Ещё есть заблуждение, гласящее примерно следующее “в виртуалках всё это не нужно, ведь это все равно работает на виртуальных сетевухах, значит, считается на CPU!”. Это не так – у хороших сетевых адаптеров с поддержкой VMq этот функционал реализуется раздельно для каждого виртуального комплекта буферов отправки и приёма, и в случае, если виртуальная система “заказывает” этот функционал через драйвер, то он включается на уровне сетевого адаптера.

Как включить IP,UDP,TCP checksum offload в Windows

Включается в свойствах сетевого адаптера. Операционная система с данными технологиями взаимодействует через минипорт, читая настройки и учитывая их в случае формирования пакетов/датаграмм/сегментов для отправки. Так как по уму это всё реализовано в NDIS 6.1, то надо хотя бы Windows Server 2008.

Работаем с Flow Control

Вы наверняка видели в настройках сетевых адаптеров данный параметр. Он есть практически на всех, поскольку технология данная (официально называемая 802.3x) достаточно простая и древняя. Но это никак не отменяет её эффективность.

Суть технологии проста – существует множество ситуаций, когда приём кадра L2 нежелателен (заполнен буфер приёма, перегружена шина данных, загружен порт получателя). В этом случае без управления потоком кадр придётся просто отбросить (обычный tail-drop). Это повлечёт за собой последующее обнаружение потери пакета, который был в кадре, и долгие выяснения на уровне протоколов более высоких уровней (того же TCP), что и как произошло. Иными словами, потеря 1.5КБ кадра превратится в каскад проблем, согласований и выяснений, на которые будет затрачено много времени и куда как больше трафика, чем если бы потери удалось избежать.

А избежать её просто – надо отправить сигнальный кадр с названием PAUSE – попросить партнёра “притормозить на чуток”. Соответственно, надо, чтобы устройство умело и обрабатывать такие кадры, и отправлять их. Кадр устроен просто – это 802.3 с вложением с кодом 0x0001, отправляемое на мультикастовый адрес 01-80-C2-00-00-01, внутри которого – предлагаемое время паузы.

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

Как включить Flow control в Windows

Включается в свойствах сетевого адаптера. Операционная система с данной технологией не взаимодействует. Не забудьте про full duplex.

Работаем с Jumbo Frame

Исторически размер данных кадра протокола Ethernet – это 1.5КБ, что в сумме со стандартным заголовком составляет 1518 байт, а в случае транкинга 802.1Q – 1522 байт. Соответственно, этот размер оставался, а скорости росли – 10 Мбит, 100 Мбит, 1 Гбит. Скорость в 100 раз выросла – а размер кадра остался. Непорядок. Ведь это обозначает, что процессор в 100 раз чаще “дёргают” по поводу получения нового кадра, что объём служебных данных также остался прежним. Совсем непорядок.

Идея jumbo frame достаточно проста – увеличить максимальный размер кадра. Это повлечёт огромное количество плюсов:

• Улучшится соотношение служебных и “боевых” данных – ведь вместо, допустим, 4х IP-пакетов можно отправить один.
• Уменьшится число переключений контекста – можно будет реже инициировать функцию “пришёл новый кадр”.
• Можно соответствующим образом увеличить размеры PDU верхних уровней – пакета IP, датаграммы UDP, сегмента TCP – и получить соответствующие преимущества.

Данная технология реализуема только на интерфейсах со скоростями 1 гбит и выше. Если Вы включите jumbo frames на уровне сетевого адаптера, а после согласуете скорость в 100 мбит, то данная настройка не будет иметь смысла.

Для увеличения максимального размера кадра есть достаточно технологических возможностей – например, длина кадра хранится в поле размером в 2 байта, поэтому менять формат кадра 802.3 не нужно – место есть. Ограничением является логика подсчёта CRC, которая становится не очень эффективна при размерах >12К, но это тоже решаемо.

Самый простой способ – выставить у адаптера данный параметр в 9014 байт. Это является тем, что сейчас “по умолчанию” называется jumbo frame и шире всего поддерживается.

Есть ли у данной технологии минусы? Есть. Первый – в случае потери кадра из-за обнаружения сбоя в CRC Вы потеряете в 6 раз больше данных. Второй – появляется больше сценариев, когда будет фрагментация сегментов TCP-сессий. Вообще, в реальности эта технология очень эффективна в сценарии “большие потоки не-realtime данных в локальной сети”, учитывайте это. Копирование файла с файл-сервера – это целевой сценарий, разговор по скайпу – нет. Замечу также, что протокол IPv6 более предпочтителен в комбинации с Jumbo frame.

Как включить Jumbo frame в Windows

Включается в свойствах сетевого адаптера (естественно, только гигабитного). Операционная система с данной технологией не взаимодействует, автоматически запрашивая у сетевой подсистемы MTU канального уровня.

Работаем с AIFS (Adaptive Inter-frame Spacing)

Данная технология предназначена для оптимизации работы на half-duplex сетях со скоростями 10/100 мегабит, и, в общем-то, сейчас не особо нужна. Суть её проста – в реальной жизни, при последовательной передаче нескольких ethernet-кадров одним хостом, между ними есть паузы – чтобы и другие хосты могли “влезть” и передать свои данные, и чтобы работал механизм обнаружения коллизий (который CSMA/CD). Иначе, если бы кадры передавались “вплотную”, хост, копирующий по медленной сети большой поток данных, монополизировал бы всю сеть для себя. В случае же full-duplex данная мера уже не сильно интересна, потому что ситуации “из N хостов одновременно может передавать только один” нет. Помните, что включая данную технологию, Вы позволяете адаптеру уменьшать межкадровое расстояние ниже минимума, что приведёт к чуть более эффективному использованию канала, но в случае коллизии Вы получите проблему – “погибнет” не только один кадр, но и соседний (а то и несколько).

Данные паузы называются или interframe gap, или interframe spacing. Минимальное штатное значение этого параметра – 96 бит. AIFS уменьшает это значение до:

• 47 бит в случае канала 10/100 МБит.
• 64 бит в случае канала 1 ГБит.
• 40 бит в случае канала 10 ГБит.

Как понятно, чисто технически уменьшать это значение до чисел менее 32 бит (размер jam) совсем неправильно, поэтому можно считать 32 бита технологическим минимумом IFS.

Процесс, который состоит в приёме потока кадров с одним IFS и отправкой с другим IFS, иногда называется IFG Shrinking.

В общем, говоря проще – негативные эффекты этой технологии есть, но они будут только на 10/100 Мбит сетях в режиме half-duplex, т.к. связаны с более сложным сценарием обработки коллизий. В остальном у технологии есть плюс, Вы получите небольшой выигрыш в части эффективности загрузки канала в сценарии “плотный поток от одного хоста”.

Да, не забудьте, что коммутатор должен “понимать” ситуацию, когда кадры идут плотным (и более плотным, чем обычно) потоком.

Как включить Adaptive Inter-frame Spacing в Windows

Включается в свойствах сетевого адаптера. Операционная система с данной технологией не взаимодействует.

Работаем с Header Data Split

Фича достаточно интересна и анонсирована только в NDIS 6.1. Суть такова – допустим, что у Вас нет Chimney Offload и Вы обрабатываете заголовки программно. К Вам приходят кадры протокола Ethernet, а в них, как обычно – различные вложения протоколов верхних уровней – IP,UDP,TCP,ICMP и так далее. Вы проверяете CRC у кадра, добавляете кадр в буфер, а после – идёт специфичная для протокола обработка (выясняется протокол сетевого уровня, выясняется содержимое заголовка и предпринимаются соответствующие действия). Всё логично.

Но вот есть одна проблема. Смотрите. Если Вы приняли, допустим, сегмент TCP-сессии, обладающий 10К данных, то, по сути, последовательность действий будет такая (вкратце):

1. Сетевая карта: Обработать заголовок 802.3; раз там 0x0800 (код протокола IPv4), то скопировать весь пакет и отдать наверх на обработку. Ведь в данные нам лезть незачем – не наша задача, отдадим выше.
2. Минипорт: Прочитать заголовок IP, понять, что он нормальный, найти код вложения (раз TCP – то 6) и скопировать дальше. Данные-то не нам не нужны – это не наша задача, отдадим выше.
3. NDIS: Ага, это кусок TCP-сессии номер X – сейчас изучим его и посмотрим, как и что там сделано

Заметили проблему? Она проста. Каждый слой читает свой заголовок, который исчисляется в байтах, а тащит ради этого путём копирования весь пакет.

Технология Header-Data Split адресно решает этот вопрос – заголовки пакетов и данные хранятся отдельно. Т.е. когда при приёме кадра в нём обнаруживается “расщепимое в принципе” содержимое, то оно разделяется на части – в нашем примере заголовки IP+TCP будут в одном буфере, а данные – в другом. Это сэкономит трафик копирования, притом очень ощутимо – как минимум на порядки (сравните размеры заголовков IP, который максимум 60 байт, и размер среднего пакета). Технология крайне полезна.

Как включить Header-Data Split в Windows

Включится оно само, как только сетевой драйвер отдаст минипорту флаг о поддержке данной технологии. Можно выключить вручную, отдав NDIS_HD_SPLIT_COMBINE_ALL_HEADERS через WMI на данный сетевой адаптер – тогда минипорт будет “соединять” головы и жо не-головы пакетов перед отправкой их на NDIS. Это может помочь в ситуациях, когда адаптер некорректно “расщепляет” сетевой трафик, что будет хорошо заметно (например, ничего не будет работать, потому что TCP-заголовки не будут обрабатываться корректно). В общем и целом – включайте на уровне сетевого адаптера, и начиная с Windows Server 2008 SP2 всё дальнейшее будет уже не Вашей заботой.

Работаем с Dead Gateway Detection

Данный механизм – один из самых смутных. Я лично слышал вариантов 5 его работы, все из которых были неправильными. Давайте разберёмся.

Первое – для функционирования этого механизма надо иметь хотя бы 2 шлюза по умолчанию. Не маршрутов, вручную добавленых в таблицу маршрутизации через route add например, а два и более шлюза.

Второе – этот механизм работает не на уровне IP, а на уровне TCP. Т.е. по сути, это обнаружение повторяющихся ошибок при попытке передать TCP-данные, и после этого – команда всему IP-стеку сменить шлюз на другой.

Как же будет работать этот механизм? Логика достаточно проста. Стартовые условия – механизм включен и параметр TcpMaxDataRetransmissions настроен по-умолчанию, то есть равен 5. Допустим, что у нас на данный момент есть 10 tcp-подключений.

1. На каждое подключение создаётся т.н. RCE – route cache entry – строчка в кэше маршрутов, которая говорит что-то вида такого “все соединения с IP-адреса X на IP-адрес Y ходят через шлюз Z, пересчитывать постоянно это не нужно, потому что полностью обрабатывать таблицу маршрутизации ради 1го пакета – уныло и долго. Ну, этакий Microsoft’овский свичинг L3 типа CEF. 🙂
2. Соединение N1 отправляет очередной сегмент TCP-сессии. В ответ – тишина. Помер.
3. Соединение N1 отправляет тот же сегмент TCP-сессии, уже имея запись, что 1 раз это не получилось. В ответ – опять тишина. Нет ACK’а. И этот сегмент стал героем.
4. Соединение N1 нервничает и отправляет тот же сегмент TCP-сессии. ACK’а нет. Соединение понимает, что так жить нельзя и делает простой вывод – произошло уже 3 сбоя отправки, что больше, чем половина значения TcpMaxDataRetransmissions, которое у нас 5. Соединение объявляет шлюз нерабочим и заказывает смену шлюза.
5. ОС выбирает следующий по приоритету шлюз, обрабатывает маршрут и генерит новую RCE-запись.
6. Счётчик ошибок сбрасывается на нуль, и всё заново – злополучный сегмент соединения N1 опять пробуют отправить.

Когда такое происходит для более чем 25% соединений (у нас их 10, значит, когда такое случится с 3 из них), то IP-стек меняет шлюз по-умолчанию. Уже не для конкретного TCP-соединения, а просто – для всей системы. Счётчик количества “сбойных” соединений сбрасывается на нуль и всё готово к продолжению.

Как настроить Dead Gateway Detection в Windows

Для настройки данного параметра нужно управлять тремя значениями в реестре, находящимися в ключе:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

Все они имеют тип 32bit DWORD и следующую логику настройки:

• TcpMaxDataRetransmissions – Количество повторных передач TCP-сегментов. От этого числа берётся критерий “Более половины”.
• TcpMaxConnectRetransmissions – То же самое, но для повторных попыток подключения, а не передачи сегментов данных.
• EnableDeadGWDetect – Включён ли вообще алгоритм обнаружения “мёртвого” шлюза. Единица – включён, нуль – отключен.

Вместо заключения

Сетевых настроек – много. Знать их необходимо, чтобы не делать лишнюю работу, не ставить лишний софт, который кричит об “уникальных возможностях”, которые, на самом деле, встроены в операционную систему, не разрабатывать дурацкие архитектурные решения, базирующиеся на незнании матчасти архитектором, и в силу множества других причин. В конце концов, это интересно.

Если как-нибудь дойдут руки – будет новая часть статьи.Дата последнего редактирования текста: 2013-10-05T07:17:01+08:00Возможно, вам будет также интересно почитать другие статьи про на нашей Knowledge BaseЗайдите на сайт под своей учётной записью, чтобы видеть комментарии под техническими статьями. Если учётной записи ещё нет — зарегистрируйтесь, это бесплатно.На различных форумах люди иногда задают вопросы типа: «У меня какие-то проблемы с сетью (например, комп «не видит» локальную сеть, не работает Интернет, и т.п.), помогите разобраться!» На что им обычно в таких случаях отвечают: «Откройте настройки сетевого адаптера и попробуйте поменять значение такого-то параметра на вот такое значение». Причём из дальнейшего диалога выясняется, что ни спрашивающий, ни отвечающий в общем-то толком даже не представляют себе, что все эти параметры означают. Я решил основательно разобраться в этой проблеме, но, к сожалению, в Интернете нашлось довольно мало конкретной информации по этой теме, так что, пришлось, что называется, собирать по крупицам, 🙂 но, тем не менее… Вся приводимая ниже информация, в первую очередь, разумеется, будет относиться к имеющемуся у меня сетевому адаптеру (за неимением других), однако, в основном, все сетевые адаптеры имеют схожие настройки (кроме параметров, специфичных для конкретного производителя/модели), различающиеся, разве что, названиями; поэтому вы с большим успехом можете отнести всё нижеизложенное и к своему адаптеру. А теперь немного о подопытном. Это сетевой адаптер «Realtek PCIe GBE Family Controller» с чипом «Realtek RTL8111C/D(L) chip (10/100/1000 Mbit)«, интегрированный в материнскую плату «GigaByte GA-G41M-ES2L rev. x.x«{даже диагностические программы выдают именно ревизию «x.x», хотя по цветовой маркировке разъёмов это вылитая «1.0»}. Причём, судя по информации с сайта GigaByte, это довольно распространённый вариант для их материнских плат. Адаптер используется на PC под управлением ОС Windows XP SP2, «отupdateнной» до SP3, а также под управлением Windows 7, на которую был установлен SP1 (использовалась версия для x86, хотя для x64 разницы нет). Параметры, специфичные для конкретной ОС, будут помечены в тексте вот так: «{WinXP}» или «{Win7}».Просмотреть список параметров можно обычным способом, через вкладку «Дополнительно» в свойствах адаптера в «Диспетчере задач«, но там существует проблема «слишком длинных названий», из-за которой эти самые названия параметров не помещаются целиком в отведённое для них узенькое окошко и, в результате, отображаются в урезанном виде без возможности просмотреть их полностью  . Поэтому, что касаемо адаптеров Realtek, я рекомендую для настройки воспользоваться специальной программой «Realtek Ethernet Diagnostic Utility» {доступна на офсайте GigaByte точно, и вроде бы на Realtek тоже}, которая не режет имена параметров и позволяет лицезреть их полностью. Помимо этого, с её помощью можно узнать текущую скорость сетевого соединения, создать виртуальное подключение (VLAN), ну и собственно, выполнить диагностику адаптера. Если же у вас не Realtek‘овский адаптер, то вероятно, у производителя вашего адаптера также имеется похожая утилита для этих целей. Что же касается «Realtek Ethernet Diagnostic Utility«, то её окно выглядит так:А вот, собственно, и сами параметры; они будут иметь двойное название: одно — русский перевод, а другое (в квадратных скобках) — оригинальное английское (на тот случай, если у вас англоязычная версия ОС; кроме того, русский перевод не всегда корректно отражает истинный смысл названия) .После имени параметра следует его краткое описание с возможными дополнениями, а затем — список возможных значений параметра с указанием их предназначения (наименования значений так же дублируются по-английски). Замечу, что для обычной работы достаточно, чтобы все параметры были установлены по умолчанию. Дополнительная информация также содержится в примечаниях после списка значений (если это необходимо).

• «Автоотключение PCIe» [Auto Disable PCIe] & «Автоотключение PHY» [Auto Disable PHY] {WinXP}

Значения:«Выкл» [Disable] — отключить возможность «Автоотключения …» {по умолчанию};»Вкл, батарея» [Enabled, Battery] — включено: при использовании батареи и при отсоединённом кабеле автоматически отключается PCIe / PHY (экономия заряда батареи);»Вкл, батарея или пер. ток» [Enabled, Battery or AC] — включено: при использовании батареи или питании от сети и при отсоединённом кабеле автоматически отключается PCIe / PHY (общая экономия электроэнергии)

• «Большой кадр» [Jumbo Frame] | [Jumbo Packet]

Позволяет увеличить размер кадра передаваемых данных (для Ethernet в целом и для TCP/IP в частности), т.е., MTU. В ситуациях, когда большие кадры составляют основную часть трафика, использование больших(Jumbo) кадров позволяет снизить загруженность CPU и повысить эффективность локальной сети. Стандартный размер кадра Ethernet (MTU) — 1500 байт (1518 с учётом всех заголовков + дополнительные байты для VLAN), в то время, как большие кадры могут содежать до 9K байт (это условное обозначение, а реальный размер такого кадра несколько меньше). Все доступные размеры зависят от конкретного адаптера.»Выкл» [Disable] — используется стандартное значение кадра Ethernet {по умолчанию};»xKB MTU» — (где x лежит в диапазоне 2 — 9 ) устанавливает длину большого кадра в x килобайт.Задействовать этот параметр можно только, если все устройства в сети а) поддерживают большие кадры и б) сконфигурированы на использование кадров ОДНОГО размера;Имейте в виду, что различные адаптеры и сетевые устройства могут по-разному вычислять размер большого кадра (например, включать или не включать размеры дополнительных заголовков);Наиболее эффективно используют эту технологию сетевые адаптеры, работающие на скоростях 1 Гбит/с и 10 Гбит/с. Известно, что использование больших кадров на скоростях 10/100 Мбит/с на некоторых адаптерах приводит к потере производительности или даже обрыву связи;Не все ОС могут работать с кадрами размером больше 4K, т.к. это может приводить к перегрузке сети при больших объёмах трафика;////////WIN7///////Уменьшение числа буферов приёма/передачи менее 256 приводит к обрыву связи при использовании больших кадров.

• «Включение по локальной сети после отключения» [Shutdown Wake-On-Lan] | [Wake-On-Lan after Shutdown]

Разрешает или запрещает опцию включения по сети (WOL) компьютера после его выключения.»Вкл» [Enable] — разрешает WOL;»Выкл» [Disable] — запрещает WOL {по умолчанию}

• «Зелёный Ethernet» [Green Ethernet]

Управляет общей функцией энергосбережения. Для Realtek состояние этой функции можно узнать с помощью «Realtek Ethernet Diagnostic Utility» (см. рис.)»Вкл» [Enable] — разрешает «зелёную» функцию;»Выкл» [Disable] — запрещает её {по умолчанию}

• «Контрольная сумма разгрузки» [Checksum Offload] {WinXP} / «Контрольная сумма разгрузки IPv4» [IPv4 Checksum Offload] {Win7}

Позволяет адаптеру проверять контрольную сумму для принимаемых пакетов (Rx) и вычислять контрольную сумму для отправляемых пакетов (Tx). Включение этой опции может повысить производительность сети и снизить загрузку CPU. Если опция отключена, расчёт и проверку контрольной суммы выполняет ОС.»Выкл» [Disable] — все контрольные суммы обрабатываются ОС;»Контрольная сумма Rx» [Rx Checksum] — Rx проверяется адаптером, Tx вычисляется ОС;»Контрольная сумма Tx» [Tx Checksum] — Tx проверяется адаптером, Rx вычисляется ОС;»Контрольная сумма Tx/Rx» [Tx/Rx Checksum] — все контрольные суммы обрабатываются адаптером {по умолчанию}

• «Разгрузка при большой отправке» [Large Send Offload] | [Offload TCP Largesend] {WinXP} / «Разгрузка при большой отправке (IPv4)» [Large Send Offload] {Win7}

Позволяет адаптеру выполнять задачу фрагментирования пакетов TCP на допустимые кадры Ethernet. Поскольку контроллер адаптера может выполнять фрагментирование гораздо быстрее, чем программное обеспечение ОС, то эта опция может повысить производительность передачи данных. Кроме того, адаптер использует меньше ресурсов CPU.»Вкл» [Enable] — разрешает аппаратное фрагментирование пакетов TCP {по умолчанию};»Выкл» [Disable] — фрагментирование осуществляетсясредствами ОС

• «Сетевой адрес» [Network Address] | [Locally Administered Address]

Замещает виртуальный, назначенный пользователем MAC-адрес адаптера. Эта настройка не замещает реальный физический (аппаратный) MAC-адрес адаптера.»Значение» [Value] — введите в это поле 12-значный шестнадцатиричный MAC-адрес (т.е., значение вида «FE123456789A» без каких-либо дефисов). Доступны значения MAC в диапазоне 000000000001 — FFFFFFFFFFFD, за исключением мультикастовых адресов (LSB старшего байта = 1), и адресов 000000000000 и FFFFFFFFFFFF;»Отсутствует» [Not Present] — при установленном в это значение переключателе, восстанавливается исходный MAC-адрес адаптера {по умолчанию}Если вы оставите поле «Значение» пустым (при установленном в это значение переключателе), также будет использован исходный MAC-адрес адаптера.

• «Скорость и дуплекс» [Speed & Duplex] | [Link Speed/Duplex Mode]

Позволяет выставить нужное значение скорости соединения и режим параллельного приёма/передачи данных — дуплекс.»Автосогласование» [Auto Negotiation] — автосогласование поддерживаемой скорости соединения и режима дуплекс с соединённым сетевым устройством {по умолчанию};»10/100 Мбит/с полудуплекс/дуплех» [10/100Mbps / Half/Full Duplex] и «1 Гбит/с дуплекс» [1000Mbps/Full Duplex] — устанавливает скорость соединения и режим дуплекс в соответствии с выбранными из выпадающего списка значениямиСамый распространённый вариант, предлагаемый провайдерами при подключении к Интернету по FTTB — PPPoE, это «100 Мбит/с дуплекс«. Именно такое значение обычно и выставляется при выборе «Автосогласования«. Однако новые сетевые драйвера Realtek для Windows XP, которые я недавно скачал с сайта GigaByte, при выборе «Автосогласования» автоматически устанавливают скорость соединения не 100 Мбит/с, а 1 Гбит/с — мелочь, а приятно :)При попытке вручную выставить значение скорости 10 Мбит/с сетевое соединение не удаётся установить, если провайдер по умолчанию поддерживает 100 Мбит/с (по крайней мере у меня так)

• «Скорость при включении по локальной сети после отключения» [WOL & Shutdown Link Speed]

Определяет начальную скорость соединения после WOL (далее, видимо устанавливается значение из параметра «Скорость и дуплекс«).»Сначала 10 Мбит/с» [10Mbps First] — устанавливает начальную скорость 10 Мбит/с {по умолчанию};»Сначала 100 Мбит/с» [100Mbps First] — устанавливает вначале 100 Мбит/с;»Не использовать автопонижение скорости» [Not Speed Down] — используется значение из параметра «Скорость и дуплекс» {Win7}Если сеть не поддерживает скорость 10 Мбит/с, то необходимо выставить «Сначала 100 Мбит/с» — это позволит избежать ненужных задержек.

• «Тегирование 802.1Q/1p VLAN» [802.1Q/1p VLAN Tagging] {WinXP}

Добавляет дополнительные 4 байта к Ethernet-фрейму (кадру), содержащие информацию о приоритете пакета и идентификаторе VLAN, которой этот пакет принадлежит. Т.е. данная опция разрешает аппаратное тегирование VLAN средствами адаптера.Значения:«Вкл» [Enable] — разрешает аппаратное тегирование VLAN;»Выкл» [Disable] — запрещает аппаратное тегирование VLAN {по умолчанию}Разумеется, эта опция имеет смысл только при установленной VLAN.

• «Управление потоком» [Flow Control]

Разрешает адаптеру генерировать или отвечать на специальные кадры управления потоком, которые помогают регулировать сетевой трафик.Сеть может оказаться перегруженной, если входящие пакеты приходят быстрее, чем устройство их может обработать, и в результате происходит потеря пакетов до тех пор, пока условия, способствующие  перегрузке не будут устранены. Механизм управления потоком позволяет обойти эту проблему и исключает риск потери пакетов.Если происходит ситуация, потенциально способствующая перегрузке сети, адаптер генерирует кадр управления потоком, который заставляет устройство на другом конце линии немедленно приостановить передачу и подождать в течение небольшого случайного отрезка времени перед попыткой возобновления передачи.»Вкл» [Enable] — разрешает управление потоком {по умолчанию};»Выкл» [Disable] — запрещает управление потоком.Некоторые адаптеры позволяют настраивать управление потоком либо только для приёма, либо только для передачи.Для получения преимущества от управления потоком, оба адаптера должны поддерживать это свойство.

• «Функции включения по сети» [Wake-On-Lan Capabilities] {WinXP}

Определяет доступные возможности WOL.»Нет» [None] — возможности WOL запрещены;»Соответствие шаблону» [Pattern Match] — WOL осуществляется с помощью пакета, содержащего специальный шаблон в зависимости от типа пробуждения (после спящего режима, ждущего режима, и т.д.);»Соответствие шаблону И Специальный пакет» [Pattern Match & Magic Packet] — комбинация этих двух возможностей {по умолчанию};»Специальный пакет» [Magic Packet] — WOL осуществляется с помощью специального пакета, соответствующего типу пробуждения

• ‘Wake on Magic Packet’ & «Wake on pattern match» {Win7}

Описание:По смыслу эти параметры представляют тот же самый функционал, что и параметр «Функции включения по сети«; просто здесь WOL настраивается для «Pattern Match» и «Magic Packet» по отдельности.»Вкл» [Enable] — опция разрешена {по умолчанию для обеих};»Выкл» [Disable] — опция запрещена

• «Автоотключение гигабитной скорости» [Auto Disable Gigabit] {Win7}

Для обеспечения целей энергосбережения, драйвер может автоматически отключить гигабитную скорость, когда сетевой кабель переподключён.»Выкл» [Disable] — отключить возможность «Автоотключения …» {по умолчанию};»Переподключение, батарея» [Re-Link, Battery] — при использовании батареи, автоматически отключается гигабитная скорость при переподключении (небольшая экономия заряда батареи);»Переподключение, батарея или пер. ток» [Re-Link, Battery or AC] — независимо от источника питания, автоматически отключается гигабитная скорость при переподключении кабеля (экономия электроэнергии). 

• «Буферы передачи» [Transmit Buffers] {Win7}

Задаёт количество буферов памяти, используемых адаптером при отправке данных. Увеличивая это значение, можно повысить производительность адаптера; правда, при этом также возрастает расход системной памяти. Поэтому, если производительность не является критическим параметром, используйте значение по умолчанию.Допустимые значения для моего «Realtek PCIe GBE Family Controller«: 1 — 128 (128 по умолчанию, так что расти некуда 🙁 ); разумеется, для вашего адаптера они могут быть другими. 

• «Буферы приема» [Receive Buffers] {Win7}

Допустимые значения для моего «Realtek PCIe GBE Family Controller«: 1 — 512 (512 , и это потолок 🙁 ); для вашей модели адаптера они могут быть и иными.

• «Контрольная сумма разгрузки TCP/UDP (IPv4/IPv6)» [TCP/UDP Checksum Offload (IPv4/IPv6)] {Win7}

По смыслу эта группа параметров аналогична «Контрольной сумме разгрузки…«; здесь обработка контрольных сумм настраивается отдельно для TCP и UDP протокола IP обеих версий.Все значения и умолчание — те же, что и для «Контрольной суммы разгрузки…«

• «Модерация прерывания» [Interrupt Moderation] {Win7}

Чтобы драйвер мог обработать приходящий пакет, адаптер генерирует сответствующее прерывание. С увеличением скоростей передачи данных количество таких прерываний также увеличивается, что, в свой черёд, увеличивает нагрузку на CPU. В результате этого снижается производительность системы.При включённой модерации прерываний, адаптер может генерировать всего одно прерывание вместо нескольких. Тогда их интенсивность снизится, а производительность — увеличится.»Вкл» [Enable] — модерация разрешена {по умолчанию};»Выкл» [Disable] — модерация не производится.

• «Получение бокового масштабирования» [Receive Side Scaling] | [RSS] {Win7}

Это механизм балансировки нагрузки, при котором обработка принимаемых пакетов (TCP — траффик) может производиться на нескольких CPU, или нескольких ядрах одного CPU (назначение логических процессоров производится динамически).»Вкл» [Enable] — разрешает RSS {по умолчанию};»Выкл» [Disable] — запрещает эту возможность.

• «Приоритет & VLAN» [Priority & VLAN] {Win7}

По смыслу это параметр «Тегирование 802.1Q/1p VLAN» с более гибкими возможностями настройки.»Приоритет & VLAN вкл» [Priority & VLAN Enabled] — разрешает аппаратный приоритет и тегирование приоритета VLAN {по умолчанию};»Приоритет & VLAN выкл» [Priority & VLAN Disabled] — отключает аппаратное тегирование;»Приоритет вкл» [Priority Enabled] — разрешает аппаратный приоритет;»VLAN вкл» [VLAN Enabled] — разрешает аппаратное тегирование VLAN

• «Разгрузка при большой отправке v2 (IPv4/IPv6)» [Large Send Offload v2 (IPv4/IPv6)] {Win7}

Оба параметра — аналоги «Разгрузка при большой отправке…«, но в отличие от первой версии они используются для пакетов размером более 64Kb.Все значения те же, что и в «Разгрузка при большой отправке…«, однако для параметра для IPv6 значение по умолчанию — «Выкл«, а не «Вкл«.На некоторых сетевых и/или системных конфигурациях при включенных параметрах группы «Разгрузка при большой отправке…» наблюдается существенная деградация производительности. В этом случае значения всех параметров «Разгрузка при большой отправке…» необходимо отключить (обычно это помогает решить проблему).

Друзья, тогда предлагаю вам принять посильное участие в улучшении моего журнала. Что можете сделать именно Вы? Для начала, оставьте хотя бы комментарий! Это покажет, что Вы не равнодушны к моему «творчеству». А мне будет приятно, в свою очередь, осознать, что, то что я делаю, нужно не только мне, но и кому-то ещё, например, друзья, Вам! И это будет неплохим стимулом для написания новых статей, определении новых тем и т.д. Далее, Вы можете подписаться на мой блог и статьмоими постоянными читателями! Это стало бы дополнительной моральной поддержкой для меня в плане моего творчества.

Используемые источники:

• https://www.atraining.ru/windows-network-tuning-2/
• https://alex-emilsson.livejournal.com/1778.html