Windows scaling heuristics что это

Обновлено: 02.07.2024

100-160 мс. У нас есть синхронная пропускная способность 1 Гбит / с в офисе, и серверы являются либо экземплярами AWS, либо физически размещены в DC США.

Первоначальный отчет состоял в том, что загрузка на новый экземпляр сервера была намного медленнее, чем могла бы быть. Это подтвердилось в тестировании и из разных мест; клиенты видели стабильные 2-5 Мбит / с на хосте из своих систем Windows.

Я iperf -s подключился к экземпляру AWS, а затем к клиенту Windows в офисе:

iperf -w1M -c 1.2.3.4

Последняя цифра может значительно отличаться в последующих тестах (капризы AWS), но обычно она составляет от 70 до 130 Мбит / с, что более чем достаточно для наших нужд. Перефразируя сеанс, я вижу:

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

И наоборот, из клиента Linux в той же сети прямой iperf -c (с использованием системного значения по умолчанию 85 КБ) дает мне:

Без какого-либо принуждения он масштабируется, как и ожидалось. Это не может быть что-то в промежуточных переходах или наших локальных коммутаторах / маршрутизаторах и, похоже, влияет на клиентов Windows 7 и 8 одинаково. Я прочитал много руководств по автонастройке, но они, как правило, вообще отключают масштабирование, чтобы обойти плохой ужасный комплект домашней сети.

Примечания

В рассматриваемом экземпляре AWS Linux применяются следующие настройки ядра sysctl.conf :

Я использовал dd if=/dev/zero | nc перенаправление /dev/null на конец сервера, чтобы исключить iperf и устранить любые другие возможные узкие места, но результаты практически одинаковы. Тесты с ncftp (Cygwin, Native Windows, Linux) масштабируются во многом так же, как и вышеупомянутые тесты iperf на соответствующих платформах.

редактировать

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

Это первая секунда захвата 1 МБ, увеличенная. Вы можете увидеть медленный запуск в действии, когда окно масштабируется и буфер увеличивается. Затем появляется это крошечное плато, равное

0,2 с, точно в той точке, в которой тест iperf окна по умолчанию выравнивается навсегда. Это, конечно, масштабируется до гораздо более высоких головокружительных высот, но любопытно, что есть такая пауза в масштабировании (значения составляют 1022 байта * 512 = 523264), прежде чем он это сделает.

Обновление - 30 июня.

Вслед за различными ответами:

Обновление 2 - 30 июня

О, так что, следуя предложению Кайла, я включил ctcp и отключил разгрузку дымохода: TCP Global Parameters

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

У меня действительно есть вопрос причины / следствия здесь, хотя: Графики имеют значение RWIN, установленное в ACK сервера для клиента. Что касается клиентов Windows, то правильно ли я считаю, что Linux не масштабирует это значение выше этой нижней точки, поскольку ограниченный CWIN клиента не позволяет заполнить даже этот буфер? Может ли быть какая-то другая причина, по которой Linux искусственно ограничивает RWIN?

Примечание: я пытался включить ECN, черт побери; но без изменений, там.

Обновление 3 - 31 июня.

Без изменений после отключения эвристики и автонастройки RWIN. Обновите сетевые драйверы Intel до последней версии (12.10.28.0) с помощью программного обеспечения, которое предоставляет функциональные настройки с помощью вкладок диспетчера устройств. Плата представляет собой встроенную сетевую плату с набором микросхем 82579 В (я собираюсь провести дополнительное тестирование от клиентов с Realtek или других поставщиков).

Сосредоточившись на сетевой карте, я попробовал следующее (в основном просто исключаю маловероятных преступников):

Увеличьте приемные буферы до 2k с 256 и передайте буферы до 2k с 512 (оба теперь максимально) - без изменений
Отключена вся выгрузка контрольной суммы IP / TCP / UDP. - Без изменений.
Отключено Большая отправка разгрузки - Nada.
Выключил IPv6, планирование QoS - Nowt.

Обновление 3 - 3 июля

Пытаясь устранить сторону сервера Linux, я запустил экземпляр Server 2012R2 и повторил тесты, используя iperf (бинарный файл cygwin) и NTttcp .

С iperf , я должен был явно указать -w1m на обе стороны , прежде чем соединение будет масштабироваться за

5 Мбит / с. (Между прочим, я мог быть проверен, и BDP

5 Мбит с задержкой 91 мс почти точно 64 КБ. Определите предел . )

Двоичные файлы ntttcp показали такое ограничение. Используя ntttcpr -m 1,0,1.2.3.5 на сервере и ntttcp -s -m 1,0,1.2.3.5 -t 10 на клиенте, я вижу гораздо лучшую пропускную способность:

8MB / s поднимает это на уровнях, которые я получал с явно большими окнами iperf . Как ни странно, 80 МБ в 1273 буферах снова = буфер 64 КБ. Еще один Wireshark показывает хороший, переменный RWIN, возвращаемый с сервера (масштабный коэффициент 256), который клиент, кажется, выполняет; так что, возможно, ntttcp искажает окно отправки.

Обновление 4 - 3 июля

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

Редкий случай хорошо изученной проблемы, которой явно нет в документации. Хорошо - будем надеяться, что кто-то найдет решение (потому что я думаю, что тоже могу это использовать). Попробуйте включить временные метки RFC 1323, так как они по умолчанию отключены в Windows, в то время как в Linux они включены по умолчанию). netsh int tcp set global timestamps=enabled Задержка 200 мс, вероятно, является алгоритмом Нагла в действии. Поскольку данные принимаются TCP по определенному соединению, он отправляет подтверждение обратно, только если выполняется одно из следующих условий: подтверждение для предыдущего полученного сегмента не было отправлено; Сегмент получен, но никакой другой сегмент не приходит в течение 200 миллисекунд для этого соединения. Есть ли какой-нибудь шанс поднять некоторые захваты пакетов от одного из более медленных отправителей? Я обновил свой OP с результатами этих тестов и ссылками на репрезентативные файлы захвата.

Вы пытались включить Compound TCP (CTCP) в своих клиентах Windows 7/8.

Повышение производительности на стороне отправителя для передачи с высоким BDP

.

Эти алгоритмы хорошо работают для небольших BDP и меньших размеров окна приема. Однако, когда у вас есть TCP-соединение с большим размером окна приема и большим BDP , таким как репликация данных между двумя серверами, расположенными по высокоскоростному каналу глобальной сети с временем прохождения сигнала 100 мс , эти алгоритмы не увеличивают окно отправки достаточно быстро, чтобы полностью использовать пропускную способность соединения .

Чтобы лучше использовать пропускную способность соединений TCP в этих ситуациях, стек TCP / IP следующего поколения включает в себя составной TCP (CTCP). CTCP более агрессивно увеличивает окно отправки для соединений с большими размерами окна приема и BDP . CTCP пытается максимизировать пропускную способность для этих типов соединений, отслеживая изменения задержки и потери. Кроме того, CTCP гарантирует, что его поведение не окажет негативного влияния на другие соединения TCP.

.

CTCP включен по умолчанию на компьютерах под управлением Windows Server 2008 и отключен по умолчанию на компьютерах под управлением Windows Vista. Вы можете включить CTCP с помощью netsh interface tcp set global congestionprovider=ctcp команды. Вы можете отключить CTCP с помощью netsh interface tcp set global congestionprovider=none команды.

Редактировать 30.06.2014

чтобы увидеть, действительно ли CTCP включен

ПО сказал:

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

CTCP агрессивно увеличивает окно отправки

В этой статье описываются следующие проблемы производительности TCP/IP:

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

Медленная скорость пропускной способности при высокой задержке и пропускной способности сети

Два сервера, расположенные на разных сайтах, подключены к сети с высокой задержкой. Пропускная способность, измеряемая с помощью средства ctsTraffic, ниже базовой.

Это происходит из-за того, что параметр TCP Window Scale не включен на любом сервере. Используйте Windows командную подсказку или Windows PowerShell, чтобы включить параметр, установив уровень автотунинга TCP для получения окна.

Чтобы включить уровень автотунинга, используйте командную подсказку

Выполните следующую команду:

Чтобы проверить, включен ли уровень автотунинга, используйте следующую команду:

Чтобы включить уровень автотунинга, используйте PowerShell

Запустите следующий командлет:

Чтобы проверить, включен ли уровень автотунинга, используйте следующий cmdlet:

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

Медленная скорость пропускной способности при низкой задержке и высокой пропускной способности сети

Два сервера подключены к одной сети с низкой задержкой и высокой пропускной способностью. При создании базовой или тестовой производительности TCP с помощью средства ctsTraffic в многоядерном сервере ЦП 0 скачет только процессор 0.

Эта проблема возникает из-за того, что функция "Получение бокового масштабирования" (RSS) или "Очередь виртуальных машин" (VMQ) не включена или не настроена правильно. Используйте VMQ, когда физический компьютер является гипервизором. Если это не так, вьйте RSS как на операционной системе (ОС), так и на сетевых картах.

Беспроводные сетевые карты не поддерживают функции RSS или VMQ.

Включить RSS для ОС

Включить RSS с помощью командной подсказки или PowerShell следующим образом:

Командная подсказка: netsh int tcp set global rss=enabled

PowerShell: Set-NetAdapterRss -Name <interface name> -Enabled $True

Включить RSS для сетевых карт

Сначала проверьте, включена ли функция RSS. Проверьте расширенные свойства сетевой карты для связанной конфигурации с помощью следующего cmdlet:

Изменения в расширенных свойствах могут привести к перерыву или потере подключения к сети. Перед внесением изменений обратитесь к документации поставщика NIC.

Выполните следующие действия, чтобы включить RSS для сетевых карт:

Запуск ncpa.cpl для открытия сетевых подключений.
Щелкните правой кнопкой мыши целевое подключение, а затем выберите Properties > Configure.
На вкладке Advanced найдите получение бокового масштабирования в списке Свойств и задай значениеВключить.
Нажмите OK.

RSS также можно включить с помощью cmdlet PowerShell:

Проблемы с сетевой сетью

В этом разделе описывается, как проверить на факты базовых сетевых проблем при измерении базовой пропускной способности или устранении проблем пропускной способности.

Чтобы получить анализ журналов уровня пакетов, проверьте проблемы с сетью, используя средство захвата сетевых пакетов (например, Microsoft Network Monitor, Wireshark или ctsTraffic).

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

Начните ведение журнала с помощью Microsoft Network Monitor или Wireshark для захвата трафика на обеих конечных точках. Вы также можете использовать встроенный Windows для захвата следующим образом:

Откройте командную подсказку в качестве администратора.

Выполните следующую команду:

При использовании команды может потребоваться несколько netsh trace захватов.

Запустите CTStraffic.exe для создания файла .csv.

Остановите ведение журнала. Для Windows встроенного средства захвата введите командную подсказку NETSH TRACE STOP в качестве администратора.

Анализ файла захвата

Вот пример, показывающий, как анализировать отфильтрованный результат. В этом сценарии средство ctsTraffic использует шаблон push (шаблон по умолчанию), который означает, что пакет отправляется от клиента на сервер.

Откройте файл захвата в Microsoft Network Monitor.

Фильтр сетевого трассировки с помощью Property.TCPRetransmit==1 && tcp.Port==4444 фильтра, который находит пакеты ретрансляторов. Повторное выполнение пакета означает, что TCP-подтверждение данной последовательности TCP от отправитель не получает.

Чтобы проанализировать файл ETL, перейдите в параметры инструментов > > Parser Profiles > Windows > Set As Active > OK.

Щелкните правой кнопкой мыши SequenceNumber в подробностях кадра и выберите Добавить выбранное значение для отображения фильтра.

Отключим предыдущий фильтр, добавив "//" следующим образом:

Нажмите Применить. Полная последовательность TCP с этим номером последовательности отображается следующим образом:

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

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

Низкая скорость интернета - это бесконечная проблема, которая время от времени мучает пользователей интернета. Иногда это проблема конфигурации сети, иногда проблема может быть связана с ПК или даже с самим провайдером.

Однако многие распространенные проблемы, связанные с DNS, TCP и IP-адресами, можно решить с помощью командной строки Windows. Ниже приведены некоторые команды, которые вы должны попробовать использовать, когда скорость интернет-соединения ниже, чем обычно.

Доступ к командной строке

Прежде чем начать, давайте сначала посмотрим, как вы можете открыть окно командной строки с повышенными правами.

Существует много способов доступа к командной строке с правами администратора, и каждый из них зависит от версии Windows. Однако простой и надежный метод - просто набрать cmd строку поиска Windows и щелкнуть правой кнопкой мыши по параметру командной строки .

Теперь выберите « Запуск от имени администратора » из контекстного меню и подтвердите диалоговое окно, чтобы открыть командную строку с правами администратора.

Примечание. Все перечисленные ниже команды лучше всего запускать в командной строке с правами администратора.

1. Обновить IP-адрес

Множество проблем может повлиять на ваш текущий IP-адрес и замедлить работу вашего интернета или браузера. Это может быть конфликт IP или даже проблема на сервере DHCP. К счастью, в большинстве случаев простой сброс IP-адреса - это все, что вам нужно для решения таких проблем.

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

Введите команду ipconfig /release и нажмите Enter, и появятся несколько больших столбцов текста.
Введите команду ipconfig /renew и снова нажмите Enter. Эта команда должна сбросить ваш IP-адрес и решить любые проблемы с интернетом, которые могут произойти из-за проблемы с IP-адресом.

Примечание . Помните, что переназначение того же IP-адреса, что и раньше, является нормальным. Дело в том, чтобы отключить и создать новое соединение.

2. Очистить кэш сопоставителя DNS

Ваш ПК хранит список имен хостов и IP-адресов веб-сайтов, которые вы посещаете, и сохраняет его в кэше сопоставителя DNS. Это облегчает создание соединения с веб-сайтом, к которому вы ранее обращались.

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

Чтобы очистить кэш сопоставителя DNS, введите команду ipconfig /flushdns и нажмите Enter. Вы должны увидеть подтверждение «Кэш сопоставителя DNS успешно очищен».

3. Сброс Winsock

Windows использует несколько сетевых сокетов для обмена информацией, и программы могут устанавливать LSP (многоуровневые поставщики услуг) для управления трафиком и перенаправлять его по правильному пути. Однако любое повреждение в сокетах или зараженный LSP может привести к медленному подключению, перенаправлению веб-сайтов или даже к отсутствию доступа к веб-сайтам.

Если это произойдет, вы можете восстановить сетевые сокеты Windows по умолчанию. Для этого введите команду netsh winsock reset в командной строке и нажмите Enter .

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

4. Используйте команду Netsh

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

Ниже приведены некоторые команды netsh , которые вы можете использовать для ускорения вашего соединения. Помните, что некоторые из этих команд могут не работать на вашем компьютере из-за ограниченной совместимости.

netsh int tcp set global chimney=enabled
netsh int tcp set global autotuninglevel=normal
netsh int tcp set supplemental
netsh int tcp set global dca=enabled
netsh int tcp set global netdma=enabled
netsh int tcp set global ecncapability=enabled
netsh int tcp set global congestionprovider=ctcp (Для пользователей windows 7)

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

Если вы столкнулись с какой-либо проблемой, замените некоторые команды со строкой ebabled на disabled

Например, команда netsh int tcp set global chimney=disabled отключит функцию TCP Offload Engine

5. Ускорение потоковой передачи

Если вы получаете наилучшую доступную скорость интернета, но веб-сайты потокового видео, такие как YouTube, работают медленно, то есть вероятность, что ваш интернет-провайдер ограничивает ваше соединение. Обычно ISP ограничивают потоковую передачу для экономии полосы пропускания. К счастью, простая команда может решить эту проблему.

В командной строке введите указанную ниже команду и нажмите Enter:

netsh advfirewall firewall add rule name="StopThrottling" dir=in action=block remoteip=173.194.55.0/24,206.111.0.0/16 enable=yes

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

Заключение

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

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

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

Disclaimer: судя по некоторым комментариям в предыдущих постах, мне стоит повторить то, с чего я начал первый пост: я не даю (и не могу давать) общеприменимых рецептов. Особенно это касается производительности, где мельчайшая неучтенная деталь может катастрофически повлиять на результат. Вернее рекомендацию то я даю: ТЕСТИРОВАНИЕ И АНАЛИЗ. Смысл моей писанины в том, чтобы дать людям как можно больше информации для анализа, ведь, чем больше понимаешь в том, как что либо работает, тем легче находить пути устранения боттлнеков.

Итак, масштабируемость пропускной способности сети. Потребуется Windows Server 2003 SP2+. Сетевая карта, поддерживающая Receive Side Scaling (можно с достаточной долей уверенности сказать, что подойдет любая серверная сетевая карта, выпущенная в последние 5 лет или любая вообще 1Gb+ NIC, хотя частенько можно увидеть RSS и на 100Mb). Устанавливаем Windows Server и драйвера на карту…

ВСЕ. Настройка завершена. RSS по умолчанию включен во всех версиях Windows, в которых он поддерживается.

Тестирование

Возьмем не особо новый Dell-овый сервер с двумя четырехядерными ксеонами:

На борту две двухпортовые 1Gb сетевые карты и одна 10Gb, но я не нашел 10Gb свитча, так что завести не удалось — ну да ладно:

На всякий случай проверяем RSS (хотя если его не будет — будет заметно и так):

Для начала выключим RSS (включал обратно я уже после тестирования, но том же окне)

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

Сеть загружена на треть:

50% одного процессора забито обработакой прерываний, еще 20% того же процессора — обработка DPC. Остальное — tcpip стек и приложение, которое отдает трафик.

Включаем RSS (скриншот выше). Процессор:

Сеть:

Треть одного процессора забита прерываниями, но DPC отлично распараллелены.

В общем, на данной конфигурации можно было бы отдавать порядка 3 гигабит (с одной сетевой карты) и только тогда мы бы встретили бутылочное горлышко.

На всякий случай, скажу, что у RSS есть менее известный родственник — Send Side Scaling. Если перед посылкой списка буферов выставить значение хеша, то прерывание после завершения посылки будет доставлено в соответствии с установленными indirection table-ами.

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

TCP Offload Engine

Если нечто подобное RSS в Linux вот-вот появится (не нашел никаких упоминаний о поддержке нормального аппаратного RSS в Linux: кто знает — дайте ссылку — проапдейчу пост). То с TOE в Linux все официально сложно. Патч от Chelsio (один из производителей high-end сетевых карт), реализующий поддержку TOE, был отклонен, а вместо этого начались какие то совершенно идиотские отмазки (при прочтении стоит иметь в виду, что BSD и Windows имеют нормальную поддержку TOE уже много лет).

Итак, что же это такое? TOE — это полная реализация TCPIP на аппаратном уровне: с подтверждением доставки, ретрансмитами при ошибках, контролем окна и пр.: сетевая карта по DMA прямо из памяти берет данные, режет на пакеты, присоединяет хедеры, а рапортует (при помощи прерываний) только в самых крайних случаях.

По умолчанию TOE стоит в automatic режиме. Смотреть Chimney Offload State:

Скриншот снимался во время активного тестирования, но в статистике видно, что ни одного «выгруженного» в сетевую карту соединения нет (о причинах позже). Включем принудительно (и через некоторое время запрашиваем статистику):

Но все же глянем, что получилось. Процессор разгрузился втрое:

Очень сильно уменьшилось количество (и время проводимое в) как ISR так и DPC:

Читайте также: