Name already in use
windows10-latency-optimization / _content / tweaks-experimental.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Данные настройки не обязательны, но в них есть немного для каждого.
Отключение патчей Meltdown, Spectre, Zombieload v2
�� Для дальнейшей настройки необходимо ознакомиться c Работа с реестром.
В своё время обнаружение Meltdown [?] и Spectre [?] наделало не мало шума, и зачастую противники этих патчей выдвигают основной аргумент в пользу его отключения – уменьшение производительности CPU. С одной стороны некоторое падение производительности действительно есть [?] , тоже самое касается и Zombieload [?] – что-то в районе пары процентов, что не критично и в пределах погрешности, с другой стороны это всё же потенциальная дыра и в приличном обществе такое выставлять на показ не принято.
✨ На слабых CPU есть смысл поэкспериментировать с данной настройкой.
⚠️ Все настройки сети необходимо тестировать, чтобы определить оптимальные для вашего качества соединения.
По-умолчанию в Windows используется механизм регулирования сети, где ограничивается обработка не мультимедийного сетевого трафика до 10 пакетов в миллисекунду (чуть больше 100 Mb/s). Смысл такого регулирования заключается в том, что обработка сетевых пакетов может быть ресурсоёмкой задачей, и может потребоваться регулирование, чтобы обеспечить приоритетный доступ CPU к мультимедийным программам. Но т.к. мы хотим избавиться от дополнительных вмешательств, то данную настройку так же рекомендуется отключить, особенно при наличии гигабитной сети.
В качестве части имени ветки мы используем *** , где *** надо заменить на Class GUID нашего сетевого адаптера.
Параметр TCPNoDelay отвечает за включение Алгоритма Нейгла [?] , который предназначен для повышения эффективности протокола TCP [?] за счёт уменьшения количества сетевых пакетов, путём объединения несколько небольших пакетов в один крупный пакет для более эффективной передачи ( nagling ). Однако было доказано [?] , что в некоторых играх он увеличивает сетевую задержку, поэтому рекомендуется отключить его.
⚠️ Имейте в виду, что отключение данной функции уменьшит скорость загрузки/отдачи из-за меньшего количества данных, передаваемых за пакет.
Параметр TcpAckFrequency определяет количество подтверждений TCP (ACK), чтобы уменьшить количество пакетов [?] . Для увеличения пропускной способности можете поэкспериментировать с небольшими значениями, превышающими 2 . Производительность Wi-Fi также может немного улучшиться, если с отключить данную функцию установив 1 .
Параметр TcpDelAckTicks служит для настройки тайм-аута TCP (ACK) [?] . Если вы отключили nagling , то данный параметр так же стоит отключить установив параметр в 0 .
⚠️ Вы также можете установить значение параметра 1 , чтобы уменьшить nagling с 200ms по умолчанию, не отключая его.
Параметр MTU , как ясно из названия, явно задаёт использовать MTU [?] равный 1500 байт [?] для избежания авто-установки в не правильное значение, т.к. по-умолчанию все сетевые устройства используют это значение равное 1500, а разные значения на устройствах могут привести с потери пакетов.
Congestion Control Provider [?] – специальные алгоритмы используемые чтобы улучшить пропускную способность. Доступны несколько вариантов:
- CTCP [?] – может улучшить пропускную способность при более высоких задержках или широкополосном соединении.
- DCTCP – используется для повышения пропускной способности на локальных каналах с низкой задержкой, если у вас есть LAN-сеть или гигабитное соединение. Используется на серверах.
- NewReno – аналогичен CTCP , но так же использует дополнительные алгоритмы Fast Retransmit & Fast Recovery.
Автоматическая настройка TCP [?] — поможет улучшить пропускную способность в сетях с высокой пропускной способностью и большими задержками. Отключение фиксирует значение для TCP Window ограничивая его до 64Kb. Normal обычно является лучшим выбором, но, возможно, стоит попробовать отключить эту настройку.
ECN Capability [?] – это механизм, который предоставляет маршрутизаторам альтернативный метод сообщения о перегрузке сети. Используется для уменьшения повторных передач пакетов. ECN предполагает, что причиной потери пакетов является перегрузка маршрутизатора, что позволяет им, испытывающим перегрузку, маркировать пакеты, из-за чего клиенты автоматически снижают скорость передачи данных, чтобы избежать дальнейшую потерю пакетов.
Включить ECN Capability :
Рекомендуется включать только при наличии перегрузки, потери пакетов или при нестабильном подключении.
⚠️ Не включайте эту настройку, если вы используете старый маршрутизатор или компьютер.
Retransmit TimeOut (RTO) [?] – сколько времени неподтверждённые пакеты будут бегать по сети, прежде чем соединение будет прервано. В сетях с высокой задержкой это может увеличить количество повторных передач пакетов.
Установить таймаут в 2s :
⚠️ Рекомендуется уменьшить таймаут для современных широкополосных сетей с малой задержкой.
Windows 10. Отключение интернета каждые
vladi105/09.01.2016, 17:46 писал: Может сбросить настройки сети к дефолтным?!
Выполните сброс параметров сетевого адаптера, маршрутов, очистке DNS и Winsock.
Отключите сетевой кабель.
Нажмите Win+X, выберите Командная строка администратор, в командной строке выполните последовательно команды:
route f
ipconfig /flushdns
netsh int ip reset
netsh int ipv4 reset
netsh int tcp reset
netsh winsock reset
Перезагрузите компьютер и настройте параметры сетевой карты.
Подключите сетевой кабель.
В общем моя ОС Win 10 в очередной раз обновилась, ну как сказать, прилетело обновление обновление и я обновил 🙂 И опять начались танцы с Ethernet адаптером. Он просто выключается спустя некоторое время, как только я запускаю торрент и начинаю скачивать большие файлы и при этом одновременно ползать в инете. Пробовал откатить драйвер, не помогло, переустановка тоже не помогла (хотя в прошлый раз этот вариант спас).
В итоге, гуглил, и пришел к выводу что нужно включть функцию в св-ве адаптера : Receive Side Scaling (RSS) — Это технология, которая равномерно распределяет нагрузку по обработке сетевых пакетов между ядрами процессора, позволяя оптимизировать производительность.
Проверим глобальные настройки TCP/IP
netsh int tcp show global
Состояние масштабирования на принимающей стороне : enabled
(Receive-Side Scaling State)
Дословный перевод — это что-то ". разбиение пакетов на потоки и использования единственного процессора для того, чтобы обработать все пакеты для данного потока. или чтобы выбрать процессор для того, чтобы обработать поток. Т.е. использование нескольких процессоров для обработки входящего потока, без RSS TCP/IP работает всегда только на одном процессоре даже если ПК многопроцессорный.
netsh int tcp set global rss=enabled (disable)
Состояние разгрузки TCP Chimney : enabled
(Chimney offload State)
Все сетевые соединения обрабатываются в сетевой карте.
netsh int tcp set global chimney=enabled (disable)
Уровень автонастройки принимающего окна : normal
(Receive Window Auto-Tuning Level)
Ну это всем известно — в простонародие автоматическое определения окна приема пакетов
netsh int tcp set global autotuninglevel=normal
— disabled — uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
— higlyrestricted — allows the receive window to grow beyond its default value, very conservatively
— restricted — somewhat restricted growth of the tcp receive window beyond its default value
— normal — default value, allows the receive window to grow to accommodate most conditions
— experimental — allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)
Поставщик надстройки контроля перегрузки : ctcp
(Add-On Congestion Control Provider)
CTCP увеличивает темп передачи с одновременным контролем размера окна и пропускной способности.
netsh int tcp set global congestionprovider=ctcp (none, ctcp, default)
Мощность ECN : enabled
(ECN Capability)
Просто говоря заминка на маршрутизаторе, снижаем передачу (пробки на дорогах).
netsh int tcp set global ecncapability=enabled (enabled, disabled, default)
рекомендуют — disable (т.к. неизвестен какой маршрутизатор в сети)
Штампы времени RFC 1323 : enabled
(RFC 1323 Timestamps)
В паре с Auto-Tuning Level, включает Window Scale (динамическое изменение размера окна приема). Windows пытается сделать размер окна наиболее разумным, учитывая задержки, помехи.
Explicit Congestion Notification (ECN) slows down outbound connections
Windows Server 2012 is the first Windows Server version to enable Explicit Congestion Notification, or ECN, in the TCP stack. This is also known as ECN Capability. Explicit Congestion Notification is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168. ECN allows end-to-end notification of network congestion without dropping packets.
Outdated network equipment dropping packets that have ECN bits set
Unfortunately, rather than responding properly or ignoring the bits, some outdated or faulty network equipment drop packets that have ECN bits set. This slows down your outbound connections, because packets need to be retransmitted without ECN bits. As retransmission intervals increase, it may take up to 10 seconds before a connection is made.
Until most network equipment supports ECN bits in packets, my advise is to disable ECN on Windows Server 2012 (R2) server. This is easily done with netsh :
Disable Windows Server Explicit Congestion Notification (ECN) capabilities
You may choose to disable Explicit Congestion Notification support on Windows Server 2012 if you experience slow outbound connections. Connections with up to a 10 second delay.
Here is how to disable ECN Capability using netsh . A reboot is not required.
First verify ECN Capability is enabled. Look for “Enabled” in the command output from
If ECN Capability is enabled, you can disable it:
A reboot is not required.
Enjoy your fast(er) outbound connections from now on!
A note on Windows TCP AutoTuningLevel: Like all modern operating systems Windows has receive window auto-tuning to dynamically adjust the receive buffer size to the throughput and latency of the link. Disabling this feature will definitely limit your Internet speeds. Auto-tuning is consistent throughout all variants of TCP and present in all modern operating systems. Read An Update on Windows TCP AutoTuningLevel (Wayback Machine archived link) for more information.
Reset TCP parameters and re-enable ECN
You can use the following netsh command to reset all TCP parameters to their default values:
Явное уведомление о перегрузке — Explicit Congestion Notification
Явное уведомление о перегрузке (ECN ) является расширением Интернет-протокола и протокола управления передачей и определено в RFC 3168 (2001). ECN разрешает сквозное уведомление о перегрузке сети без потери пакетов. ECN — это дополнительная функция, которая может использоваться между двумя конечными точками с поддержкой ECN, если базовая сетевая инфраструктура также поддерживает ее.
Обычно сети TCP / IP сигнализируют о перегрузке, отбрасывая пакеты. После успешного согласования ECN маршрутизатор с поддержкой ECN может установить метку в заголовке IP вместо отбрасывания пакета, чтобы сигнализировать о надвигающейся перегрузке. Получатель пакета повторяет указание перегрузки отправителю, что снижает его скорость передачи, как если бы он обнаружил потерянный пакет.
Вместо того, чтобы правильно реагировать или игнорировать биты, некоторое устаревшее или неисправное сетевое оборудование исторически отбрасывало или искажало пакеты с установленными битами ECN. По состоянию на 2015 год измерения показали, что доля веб-серверов в общедоступном Интернете, для которых настройка ECN предотвращает сетевые подключения, была уменьшена до менее 1%.
Пассивная поддержка существовала в Ubuntu Linux с 12.04 и Windows Server с 2012 года. Пассивная поддержка на самых популярных веб-сайтах увеличилась с 8,5% в 2012 году до более 70% в мае 2017 года. Внедрение через Интернет теперь требует, чтобы клиенты активно запрашивали ECN. В июне 2015 года Apple объявила, что ECN будет включена по умолчанию для ее поддерживаемых и будущих продуктов, чтобы способствовать внедрению ECN-сигнализации во всей отрасли.
Содержание
- 1 Операция
- 1.1 Работа ECN с IP
- 1.2 Работа ECN с TCP
- 1.2.1 ECN и управляющие пакеты TCP
- 3.1 Поддержка ECN в TCP хостами
- 3.1.1 Microsoft Windows
- 3.1.2 BSD
- 3.1.3 Linux
- 3.1.4 Mac OS X
- 3.1.5 iOS
- 3.1.6 Solaris
Работа
Требуется ECN специальная поддержка как на уровне Интернета, так и на уровне транспортного уровня по следующим причинам:
- В TCP / IP маршрутизаторы работают на уровне Интернета, а скорость передачи данных обрабатывается конечными точками на транспортном уровне..
- Перегрузка может обрабатываться только переданным э-э, но поскольку известно, что это произошло только после того, как пакет был отправлен, должен быть эхо-сигнал индикации перегрузки от получателя к передатчику.
Без ECN эхо-сигнал индикации перегрузки достигается косвенно путем обнаружения потери пакеты. В случае ECN перегрузка указывается установкой поля ECN в IP-пакете на CE и передается от приемника передатчику путем установки правильных битов в заголовке транспортного протокола. Например, при использовании TCP индикация перегрузки отражается путем установки бита ECE.
Работа ECN с IP
ECN использует два наименее значимых (крайних правых) бита поля Traffic Class в IPv4 или заголовок IPv6 для кодирования четырех разных кодовых точек:
- 00 — транспорт без поддержки ECN, без ECT
- 10 — транспорт с поддержкой ECN, ECT (0)
- 01 — ECN Capable Transport, ECT (1)
- 11 — Встречная перегрузка, CE.
Когда обе конечные точки поддерживают ECN, они маркируют свои пакеты с помощью ECT (0) или ECT (1). Маршрутизаторы рассматривают кодовые точки ECT (0) и ECT (1) как эквивалентные. Если пакет проходит через очередь активного управления очередью (AQM) (например, очередь, которая использует случайное раннее обнаружение (RED)), которая испытывает перегрузку, и соответствующий маршрутизатор поддерживает ECN, он может изменить кодовую точку на CE вместо отбрасывания пакета. Это действие называется «маркировкой», и его цель — информировать принимающую конечную точку о надвигающейся перегрузке. В принимающей конечной точке эта индикация перегрузки обрабатывается протоколом верхнего уровня (протокол транспортного уровня ) и должна быть возвращена передающему узлу, чтобы сообщить ему о снижении скорости передачи.
Поскольку индикация CE может эффективно обрабатываться только поддерживающим ее протоколом верхнего уровня, ECN используется только в сочетании с протоколами верхнего уровня, такими как TCP, которые поддерживают контроль перегрузки и иметь метод для отражения индикации CE передающей конечной точке.
Работа ECN с TCP
TCP поддерживает ECN, используя два флага в заголовке TCP. Первый, ECN-Echo (ECE), используется для отражения индикации перегрузки (т. Е. Сигнализирует отправителю об уменьшении объема информации, которую он отправляет). Второй, уменьшение окна перегрузки (CWR), подтверждает получение эхо-сигнала индикации перегрузки. Использование ECN в TCP-соединении необязательно; для использования ECN его необходимо согласовать при установлении соединения путем включения подходящих опций в сегменты SYN и SYN-ACK.
Когда ECN согласован для TCP-соединения, отправитель указывает, что IP-пакеты, которые несут TCP-сегменты этого соединения, переносят трафик от ECN Capable Transport, помечая их кодовой точкой ECT. Это позволяет промежуточным маршрутизаторам, поддерживающим ECN, помечать эти IP-пакеты кодовой точкой CE вместо того, чтобы отбрасывать их, чтобы сигнализировать о приближающейся перегрузке.
После получения IP-пакета с кодовой точкой «перегрузка» приемник TCP передает это сообщение о перегрузке, используя флаг ECE в заголовке TCP. Когда конечная точка получает сегмент TCP с битом ECE, она уменьшает свое окно перегрузки, как при отбрасывании пакета. Затем он подтверждает индикацию перегрузки, отправляя сегмент с установленным битом CWR.
Узел продолжает передавать сегменты TCP с установленным битом ECE до тех пор, пока он не получит сегмент с установленным битом CWR.
Чтобы увидеть затронутые пакеты с tcpdump, используйте предикат фильтра (tcp [13] 0xc0! = 0) .
ECN и управляющие пакеты TCP
Поскольку Протокол управления передачей (TCP) не выполняет контроль перегрузки для управляющих пакетов (чистые ACK, SYN, сегменты FIN), управляющие пакеты обычно не помечаются как поддерживающие ECN.
Предложение от 2009 г. предлагает помечать пакеты SYN-ACK как поддерживающие ECN. Было показано, что это усовершенствование, известное как ECN +, значительно улучшает производительность короткоживущих TCP-соединений.
Работа ECN с другими транспортными протоколами
ECN также определена для другого транспортного уровня протоколы, которые выполняют контроль перегрузки, в частности, DCCP и Stream Control Transmission Protocol (SCTP). Общий принцип аналогичен TCP, хотя детали кодирования по сети отличаются.
Можно использовать ECN с протоколами, расположенными выше UDP. Однако UDP требует, чтобы управление перегрузкой выполнялось приложением, а ранние протоколы на основе UDP, такие как DNS, не использовали ECN. Более поздние протоколы на основе UDP, такие как QUIC, используют ECN для контроля перегрузки.
Влияние на производительность
Поскольку ECN эффективен только в сочетании с политикой Active Queue Management (AQM), преимущества ECN зависят от того, какой именно AQM используется. Однако некоторые наблюдения, похоже, справедливы для разных AQM.
Как и ожидалось, ECN уменьшает количество пакетов, отброшенных TCP-соединением, что, избегая повторной передачи, уменьшает задержку и особенно дрожание. Этот эффект наиболее заметен, когда TCP-соединение имеет единственный ожидающий сегмент, когда удается избежать тайм-аута RTO ; это часто имеет место для интерактивных подключений, таких как удаленный вход в систему, и транзакционных протоколов, таких как HTTP-запросы, диалоговая фаза SMTP или SQL-запросы.
Влияние ECN на массовую пропускную способность менее очевидно, поскольку современные реализации TCP довольно хорошо справляются с своевременной повторной отправкой отброшенных сегментов, когда окно отправителя велико.
Было обнаружено, что использование ECN снижает производительность в сильно перегруженных сетях при использовании алгоритмов AQM, которые никогда не отбрасывают пакеты. Современные реализации AQM избегают этой ловушки, отбрасывая, а не маркируя пакеты при очень высокой нагрузке.
Реализации
Многие современные реализации набора протоколов TCP / IP имеют некоторую поддержку ECN; однако они обычно поставляются с отключенным ECN.
Поддержка ECN в TCP хостами
Microsoft Windows
Версии Windows, начиная с Windows Server 2008 и Windows Vista, поддерживают ECN для TCP. Начиная с Windows Server 2012, он включен по умолчанию в версиях Windows Server, поскольку используется протокол управления передачей данных центра данных (DCTCP). В предыдущих версиях Windows и несерверных версиях он отключен по умолчанию.
Поддержка ECN может быть включена с помощью команды оболочки, такой как netsh interface tcp set global ecncapability = enabled.
В FreeBSD ECN для TCP можно настроить с помощью net.inet.tcp.ecn.enable sysctl. По умолчанию он включен только для входящих соединений, которые его запрашивают. Его также можно включить для всех подключений или полностью отключить.
NetBSD 4.0 реализует поддержку ECN для TCP; его можно активировать через интерфейс sysctl, установив 1 в качестве значения для параметра sysctl net.inet.tcp.ecn.enable.
Аналогично, sysctl net.inet.tcp.ecn можно использовать в OpenBSD.
Linux
Начиная с версии 2.4.20 ядра Linux., выпущенный в ноябре 2002 г., Linux поддерживает три режима работы ECN для TCP, настроенных через интерфейс sysctl путем установки параметра / proc / sys / net / ipv4 / tcp_ecn на единицу. из следующих значений:
- 0 — отключить ECN и не инициировать и не принимать его
- 1 — включить ECN при запросе входящих соединений, а также запрашивать ECN при попытках исходящего соединения
- 2 — (по умолчанию) включить ECN, когда запрашивается входящими соединениями, но не запрашивает ECN для исходящих соединений
Начиная с версии 4.1 ядра Linux, выпущенной в июне 2015 года, механизм tcp_ecn_fallback, как указано в RFC 3168, раздел 6.1.1.1, включен по умолчанию, когда включен ECN (значение 1). Механизм отката пытается установить соединение ECN при первоначальной настройке исходящих соединений с постепенным откатом для передач без возможности ECN, смягчая проблемы с хостами, не допускающими ECN, или межсетевыми экранами.
Mac OS X
Mac OS X 10.5 и 10.6 реализуют поддержку ECN для TCP. Он управляется с помощью логических sysctl переменных net.inet.tcp.ecn_negotiate_in и net.inet.tcp.ecn_initiate_out. Первая переменная включает ECN для входящих соединений, для которых уже установлены флаги ECN; второй пытается инициировать исходящие соединения с включенным ECN. Обе переменные по умолчанию равны 0, но могут быть установлены в 1 для включения соответствующего поведения.
В июне 2015 года Apple Inc. объявила, что в OS X 10.11 по умолчанию будет включена функция ECN. Этого никогда не происходило, в macOS Sierra ECN включен для 50 процентов TCP-сессий
В июне 2015 года Apple Inc. объявила, что iOS 9, его следующая версия iOS, будет поддерживать ECN и включать ее по умолчанию. Согласование TCP ECN включено для 5% случайно выбранных подключений через Wi-Fi / Ethernet в iOS 9 и 50% случайно выбранных подключений через Wi-Fi / Ethernet и нескольких операторов сотовой связи в iOS 10 и 100. % для iOS 11
Solaris
Ядро Solaris поддерживает три состояния ECN для TCP:
- никогда — нет ECN
- активен — используйте ECN
- пассивный — объявлять о поддержке ECN только по запросу.
Поведение по умолчанию — пассивное. Начиная с Solaris 11, полное использование ECN можно активировать с помощью ipadm set-prop -p ecn = active tcp.
Поддержка ECN в IP маршрутизаторами
Поскольку маркировка ECN в маршрутизаторах в зависимости от некоторой формы активного управления очередью, маршрутизаторы должны быть настроены с подходящей дисциплиной очереди для выполнения маркировки ECN.
Маршрутизаторы Cisco IOS выполняют маркировку ECN, если они настроены с помощью дисциплины организации очереди WRED, начиная с версии 12.2 (8) T.
Маршрутизаторы Linux выполняют маркировку ECN, если они настроены с одной из дисциплин очереди RED или GRED с явным параметром ecn, с использованием дисциплины sfb, с помощью CoDel Дисциплина Fair Queuing (fq_codel) или дисциплина CAKE.
Современные реализации BSD, такие как FreeBSD, NetBSD и OpenBSD, поддерживают маркировку ECN в ALTQ реализация очередей для ряда дисциплин организации очередей, в частности КРАСНЫЙ и Синий. FreeBSD 11 включает CoDel, PIE, FQ-CoDel и FQ-PIE реализацию дисциплин очередей в ipfw / dummynet framework с возможностью маркировки ECN.
TCP центра обработки данных
Протокол управления передачей данных центра обработки данных (TCP или DCTCP) использует ECN для улучшения алгоритма управления перегрузкой протокола управления передачей. Он используется в сетях центров обработки данных . В то время как стандартный алгоритм управления перегрузкой TCP способен обнаруживать только наличие перегрузки, DCTCP, используя ECN, может измерить степень перегрузки.
DCTCP изменяет приемник TCP, чтобы всегда ретранслировать точную маркировку ECN входящих пакетов за счет игнорирования функции, предназначенной для сохранения надежности сигнализации. Это делает отправителя DCTCP уязвимым к потере ACK от получателя, и у него нет механизма для обнаружения или устранения этой проблемы. По состоянию на июль 2014 года алгоритмы, обеспечивающие эквивалентную или лучшую обратную связь с приемником при более надежном подходе, являются активной темой исследования.