За что отвечает tcpdelackticks
За что отвечает tcpdelackticks
Данные настройки не обязательны, но в них есть немного для каждого.
Отключение патчей Meltdown, Spectre, Zombieload v2
💡 Для дальнейшей настройки необходимо ознакомиться c Работа с реестром.
✨ На слабых CPU есть смысл поэкспериментировать с данной настройкой.
⚠️ Все настройки сети необходимо тестировать, чтобы определить оптимальные для вашего качества соединения.
По-умолчанию в Windows используется механизм регулирования сети, где ограничивается обработка не мультимедийного сетевого трафика до 10 пакетов в миллисекунду (чуть больше 100 Mb/s). Смысл такого регулирования заключается в том, что обработка сетевых пакетов может быть ресурсоёмкой задачей, и может потребоваться регулирование, чтобы обеспечить приоритетный доступ CPU к мультимедийным программам. Но т.к. мы хотим избавиться от дополнительных вмешательств, то данную настройку так же рекомендуется отключить, особенно при наличии гигабитной сети.
⚠️ Имейте в виду, что отключение данной функции уменьшит скорость загрузки/отдачи из-за меньшего количества данных, передаваемых за пакет.
Congestion Control Provider [?] – специальные алгоритмы используемые чтобы улучшить пропускную способность. Доступны несколько вариантов:
ECN Capability [?] – это механизм, который предоставляет маршрутизаторам альтернативный метод сообщения о перегрузке сети. Используется для уменьшения повторных передач пакетов. ECN предполагает, что причиной потери пакетов является перегрузка маршрутизатора, что позволяет им, испытывающим перегрузку, маркировать пакеты, из-за чего клиенты автоматически снижают скорость передачи данных, чтобы избежать дальнейшую потерю пакетов.
Включить ECN Capability :
Рекомендуется включать только при наличии перегрузки, потери пакетов или при нестабильном подключении.
⚠️ Не включайте эту настройку, если вы используете старый маршрутизатор или компьютер.
Retransmit TimeOut (RTO) [?] – сколько времени неподтверждённые пакеты будут бегать по сети, прежде чем соединение будет прервано. В сетях с высокой задержкой это может увеличить количество повторных передач пакетов.
Установить таймаут в 2s :
⚠️ Рекомендуется уменьшить таймаут для современных широкополосных сетей с малой задержкой.
Тонкая настройка параметров TCP/IP под толстые каналы
Пропускная способность локальных сетей и Интернет-каналов неуклонно растет, однако вместе с ней растут и потребности, вызывающие естественное желание выжать из TCP/IP-стека максимум возможного, чем мы сейчас, собственно, и займемся, главным образом акцентируя внимания на Windows Server 2003, хотя описанные технология оптимизации справедливы и для рабочих станций, собранных на базе W2K/XP.
Введение
По поводу кручения настроек TCP/IP существуют два диаметрально противоположных мнения: многие администраторы (а вместе с ними и авторы популярных книг!) считают, что разработчики уже сделали все, что нужно и любое вмешательство в этот четко отлаженный механизм может только навредить. В то же самое время в Интернете валяется множество руководств, обещающих если не путевку в рай, то радикальное увеличение производительности ценою изменения пары-тройки ключей в системном реестре.
Истина, как водится, где-то посередине. Операционные системы уже давно научились автоматически распознавать тип подключения, выбирая соответствующий ему набор настроек по умолчанию. Адаптивные алгоритмы динамически подстраиваются под характеристики канала и неквалифицированные «указания» пользователя действительно только мешают. Однако адаптивным алгоритмам свойственно ошибаться, а настройки по умолчанию далеко не всегда соответствуют характеристикам конкретно взятых каналов связи, разброс которых просто колоссален.
Какой прирост производительности может дать оптимизация параметров TCP/IP, при условии, что она выполнена правильно? Зависит от того, насколько настройки по умолчанию близки к свойствам используемого канала. В среднем, следует ожидать 20%. 30% выигрыша, однако в «клинических» случаях скорость увеличивается в несколько раз!
Прежде чем приступать к оптимизации
Вместо того, чтобы, засучив рукава, с первых же строк бросаться в бой, лучше сперва покурить и подумать. Допустим, мы имеем 10 мегабитный канал и скачиваем/раздаем файлы с превалирующей скоростью порядка мегабайта в секунду. Понятно, что никакими ухищрениями нам не удастся поднять производительность на сколь-нибудь заметную величину. Так стоит ли возиться?! К тому же, достаточно большое количество администраторов умышленно ущемляет отдачу в районе 50-100 Кбайт/с, предотвращая перегрузку сети. Какая уж тут оптимизация.
Также не стоит забывать и о том, что чрезмерная фрагментация дискового пространства существенно замедляет скорость отдачи/приема файлов, что является одной из основных причин замедления загрузок web-страничек у конечных пользователей.
В общем, прежде чем лезть в TCP/IP стек, следует убедиться, что все остальные возможные причины устранены и узким местом являются именно настройки сетевых протоколов, а не что-то иное (внимание: «убедиться» это совсем не тоже самое, что «убедить себя»).
MTU задет наибольший возможный размер отправляемого IP-пакета (вместе с заголовком), нарезая отправляемые данные на порции фиксированного размера. Чем больше MTU, тем ниже накладные расходы на передачу служебной информации, а, значит, выше «КПД» канала. С другой стороны, маршрутизаторы сваливают пакеты, поступающие от разных узлов, в общую очередь и потому гораздо выгоднее отправить один большой пакет, чем два маленьких, причем чем сильнее загружен маршрутизатор, тем больший выигрыш мы получим.
Рисунок 1. MTU и MSS.
Так в чем же дело?! Выкручиваем MTU до предела и. скорость падает до нуля. Почему? Причина в том, что с ростом размера пакетов увеличивается и время, необходимое для их повторной передачи в том случае, если пакет потерян или искажен. К тому же, промежуточные узлы имеют свои собственные настройки, и если размер передаваемого пакета, превышает текущий MTU, пакет разрезается на два или более пакетов, (т.е. фрагментируется) и эти фрагменты собираются воедино только на узле-приемнике, в результате чего пропускная способность уменьшается. Причем, если MTU узла отправителя лишь чуть-чуть превышает MTU промежуточного узла, то второй пакет состоит практически из одного заголовка, в результате чего зависимость скорость передачи от размера превращается в характерную пилообразную кривую (см. рис. 2).
Значения MTU, используемые Windows Server 2003 по умолчанию, приведены в таблице 1, однако при желании их можно изменить.
Рисунок 2. Зависимость скорости передачи данных от размера MTU (по данным http://member.nifty.ne.jp/oso/faq.mtu-faq.html).
Рисунок 3. Тонкая настройка TCP/IP параметров через «Редактор Реестра».
Рисунок 4. «Черными дырами» называют маршрутизаторы, не отправляющие ICMP-сообщения о факте фрагментации ретранслируемого пакета, что создает большие проблемы при попытке определения оптимального значения MTU.
В подавляющем большинстве случаев использование опций EnablePMTUDiscovery и EnablePMTUDiscovery приводит к снижению производительности и значение MTU лучше выбирать, отталкиваясь от таблицы 2, или действовать методом перебора.
Параметр | Канал с скоростью = 128 | |
MTU (Maximum Transmission Unit) | 576 | 1500 |
MSS (Maximum Segment Size) | 536 | 1460 |
Таблица 1. Значения MTU и MSS по умолчанию в Microsoft Windows Server 2003.
MTU (байт) | Протокол | Нормативный RFC |
576 | по умолчанию | 879 |
1500 | PPP по умолчанию | 1134 |
296 | PPP (low relay) | 1144 |
1500 | Ethernet | 895 |
1006 | SLIP | 1055 |
1492 | PPPOE | 2516 |
Таблица 2. Значения MTU, автоматически выбираемые Microsoft Windows Server 2003 в зависимости от типа подключения.
TCP Receive Window
Промежуток времени между отправкой пакета и его получением называется латентностью (latency) и эта латентность в зависимости от типа и загруженности сети варьируется от 20 ms (и менее) до 100 ms (и более). Легко посчитать, что если бы подтверждался каждый сегмент, до даже в низколатентной сети реальная скорость передачи заметно отставала от ее реальных возможностей и была бы равна MTU / (2 * latency), что образует предел в 6 мегабит/сек, независящий от пропускной способности. Кошмар! Ну, как дальше жить?!
Вот потому-то создатели TCP/IP и разрешили узлу «A» отправлять более одного сегмента, не дожидаясь подтверждения. Максимальное количество сегментов, которые можно передать до прихода подтверждения и называется размером TCP-окна (процесс передачи хорошо проиллюстрированном на анимированном gif’e: http://cable-dsl.home.att.net/rwinanim.htm). Почему этот параметр так важен для достижения наибольшей производительности?
Допустим, мы имеем 10-мегабитный канал и передаем 7 сегментов по 1460 байт каждый, потратив на этого 8 ms. Если латентность составляет 100 ms, то. 100 ms + 92 ms = 192 ms. Мы, как идиоты, ждем подтверждения целых 192 ms и 96% времени узел «А» проводит в бездействии, используя лишь 4% пропускной способности канала. Это, конечно, крайний случай, но все-таки не настолько далекий от истины, как можно было бы подумать.
В процессе установки соединения, узел «A» предлагает узлу «B» установить размер окна, равный 16 Кбайтам (значение по умолчанию, прописанное в параметре ТсрWindowSize реестра, который при желании можно изменить). Размер окна всегда округляется до целого количества сегментов (см. параметр MSS).
Если размер окна превышает 64 Кбайт, система активирует алгоритм автоматического масштабирования, который, впрочем, работает только в том случае, если узел B также поддерживает этот механизм, поэтому лучше задавать размер TCP-окна вручную, руководствуясь таблицей 3. (Однако следует помнить, что слишком большое окно забивает канал пакетами, вызывая перегрузку сети, препятствующую пересылке уведомлений, в результате чего производительность падает).
Минимально необходимый размер TCP-окна | ||||||
Скорость канала в (Килобит/сек) | ||||||
500 | 1000 | 1500 | 2000 | 2500 | ||
Латентность канала (ms) | 50 | 2K | 5K | 7K | 10K | 12K |
100 | 5K | 10K | 15K | 20K | 24K | |
150 | 7K | 15K | 22K | 29K | 37K | |
200 | 10K | 20K | 29K | 39K | 49K | |
250 | 12K | 24K | 37K | 49K | 61K | |
Windows 9x/NT по умолчанию | 8K | |||||
Windows Me/2000/XP Server 2003 по умолчанию | Скорость канала | |||||
100 Мегабит/сек | ||||||
8 KB | 17 KB | 64 KB | ||||
Рекомендуемые значения | 32-63K |
Таблица 3. Рекомендуемые значения размера TCP-окна в зависимости от характеристик канала (по данным http://cable-dsl.home.att.net/).
Если клиенты локальной сети работают через Proxy-сервер, то для достижения максимальной производительности достаточно изменить размер TCP-окна непосредственно на самом сервере.
При работе же через NAT необходимо настроить TCP-окно на каждой рабочей станции, подключенной к локальной сети.
Медленный старт и выборочное подтверждение
Для предотвращения перегрузок сети в протокол TCP был введен так называемый «медленный старт» («slow start»), подробно описанный в RFC 1122 и RFC 2581.
При создании нового TCP/IP соединения система устанавливает размер окна, равный одному сегменту. После получения подтверждения размер окна увеличивается вдвое и так продолжается вплоть до достижения максимально возможного размера.
Кроме того, система поддерживает специальный параметр Slow Start Threshold Size (Пороговый Размер [окна] Медленного Старта), по умолчанию равный 65636, но после распознавания ситуации «перегрузка сети», принимающий значение W / 2 и в дальнейшем является верхней границей экспоненциального роста параметра CW, что вызывает драматическое падение производительности (см. рис. 6).
Рисунок 6. Уменьшение размеров TCP-окна при обнаружении перегрузки сети.
Выборочное подтверждение передачи позволяет осуществлять повторную передачу неподтвержденных сегментов в одном окне (при неактивном SACK’е потерянные сегменты передаются один за другим в индивидуальном порядке). Другими словами, узел «А» повторно передает узлу «B» только реально потерянные сегменты, а не весь блок, в состав которого входят и успешно принятые пакеты. Очевидно, что максимальный прирост производительности будет наблюдаться на нестабильных каналах связи, регулярно теряющих пакеты.
Для активации алгоритма SACK достаточно установить параметр реестра SackOpts в значение «1» (значение по умолчанию для W2K и XP).
Время, работающее против нас
С подтвержденными сегментами все ясно. Если подтверждение пришло, сегмент можно считать успешно доставленным. Весь вопрос в том, сколько это самое подтверждение ждать и когда начинать повторную пересылку.
Очевидно, что на нестабильных каналах, страдающих хроническими задержками, количество разрывов соединений можно сократить путем увеличения параметра TcpMaxDataRetransmissions до любой разумной величины (но не больше FFFFFFFFh). С другой стороны, для повышения производительности и «нейтрализации» пагубного влияния потерянных пакетов на быстрых каналах с малым временем задержки значение TcpInitialRTT рекомендуется уменьшить до одной секунды.
Главный недостаток статического таймера в его неспособности реагировать на кратковременные изменения характеристик канала связи. Выбранное системой время ожидания подтверждения оказывается то мало, то велико. Производительность падает, пользователь рвет и мечет, а пропускная способность «плавает» в очень широких пределах, заметно отставая от ожидаемой.
К сожалению, задержка, выбранная компанией Microsoft по умолчанию, близка к латентности сетей с большими задержками, что сводит на нет все достоинства данного алгоритма и для повышения производительности значение TcpDelAckTicks рекомендуется увеличить в несколько раз. Соответственно, на низколатентных сетях его лучше уменьшить, ликвидируя никому не нужные простои.
Значения данного параметра могут варьироваться в диапазоне от 0 до 6, выражаемом в десятых долях секунды, т.е. единица соответствует 100 ms, а нуль трактуется как запрет на использование задержанных подтверждений.
При использовании TCP-окон большого размера рекомендуется задействовать алгоритм временных меток (TCP-Timestamps), описанный в RFC 1323, и автоматически адаптирующий значение таймера повторной передачи даже в условиях быстро меняющихся характеристик канала связи. За это отвечает параметр Tcp1323Opts, который, будучи установленным в значение 3, разрешает использование всех расширений RFC 1323.
Заключение
В статье рассмотрены лишь некоторые опции TCP/IP-протокола, в наибольшей степени ответственные за его производительность. Но помимо них существует и другие, за разъяснением которых мы оправляем читателя по ссылкам ниже.
Медленная производительность возникает при копировании данных на сервер TCP с помощью Windows API sockets
В этой статье данная статья предоставляет обходные пути решения проблемы, при которой медленная производительность возникает при копировании данных на сервер TCP с помощью Windows API sockets.
Применяется к: Windows Server 2012 R2, Windows 10 — все выпуски
Исходный номер КБ: 823764
Симптомы
При запуске программы, использующей API Windows sockets, при копировании данных на TCP-сервере может возникнуть медленная производительность.
Если сделать трассировку сети с помощью сетевого обнюхиватель, например Microsoft Network Monitor, сервер TCP отправляет сегмент TCP ACK в последний сегмент TCP в потоке данных TCP в отложенном отложенном времени подтверждения (также известном как отложенный ACK-отоператор). По умолчанию для Windows операционных систем значение этого времени составляет 200 миллисекунд (ms). Типичный поток данных для отправки данных в 64 килобайта (КБ) похож на следующую последовательность:
Клиент->Server 1460 bytes
Клиент->Server 1460 bytes
Сервер->ACK клиента
Клиент->Server 1460 bytes
Клиент->Server 1460 bytes
Сервер->ACK клиента
.
Клиент->Server 1460 bytes
Клиент->Server 1460 bytes
Сервер->клиент ACK-PUSH
Bytes client->Server 1296
-> ACK 200 ms
Причина
Эта проблема возникает из-за архитектурного поведения API Windows sockets и afd.sys. Эта проблема возникает, если все следующие условия верны:
Программа Windows sockets использует неблокирующие розетки.
Один вызов отправки или вызов WSASend заполняет весь буфер отправки в основном розетке.
Например, программа использует функцию Windows sockets для изменения буфера отправки розетки по умолчанию до 32 КБ во время процедур инициализации setsockopt розетки:
Позже, когда программа отправляет данные, она отправляет вызов отправки или вызов WSASend и отправляет 64 КБ данных во время каждого отправки:
В этом сценарии при каждом вызове 64 КБ данных программа возвращает код ошибки SOCKET_ERROR при заполнении буфера розетки 32-КБ. После вызова функции WSAGetLastError программа получает код ошибки WSAEWOULDBLOCK. Большинство программ используют функцию выбора Windows для проверки состояния розетки. В этом сценарии функция выбора не сообщает о том, что розетка является writable, пока клиент не получит выдающийся сегмент TCP ACK. По умолчанию в Windows среде это может занять до 200 мс из-за задержки алгоритма подтверждения.
Удаленный TCP-сервер подтверждает все сегменты TCP перед отправкой клиентом последнего сегмента TCP с набором push-бита.
Обходной путь
Чтобы решить эту проблему, используйте любой из следующих методов.
Метод 1. Использование блокирующих розеток
Эта проблема возникает только с незаблокирующимися розетками. При использовании блокирующего розетки эта проблема не возникает, так как afd.sys по-разному обрабатывает буфер розетки. Дополнительные сведения о блокировке и неблокировке программирования розетки см. в документации microsoft Platform SDK.
Метод 2. Сделайте размер буфера отправки для розетки больше размера буфера, чем размер буфера отправки программы
Чтобы изменить буфер отправки розетки, используйте функцию Windows sockets для определения текущего размера буфера отправки (SO_SNDBUF), а затем используйте функцию для определения размера буфера отправки getsockopt setsockopt розетки. По завершению значение SO_SNDBUF должно быть не менее чем на 1 byte больше размера буфера отправки программы.
Измените вызов отправки или вызов WSASend, чтобы указать размер буфера не менее чем на 1 byte меньше SO_SNDBUF значения. В более ранних примерах в разделе «Причина» этой статьи можно изменить вызов setockopt на следующее значение,
или вы можете изменить отправку вызова на следующее значение:
Вы также можете использовать любое сочетание этих значений.
Метод 3. Изменение параметров TCP/IP на сервере TCP
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт:
322756 Создание резервной копии и восстановление реестра Windows
Измените параметры TCP/IP на сервере TCP, чтобы сразу же подтвердить входящие сегменты TCP. Это решение лучше всего работает в среде с большой клиентской базой установки и в которой невозможно изменить поведение программы. Для сценариев, в которых удаленный сервер TCP работает на Windows сервере, необходимо изменить реестр удаленного сервера. В других операционных системах см. документацию операционной системы для получения сведений об изменении отложенного времени подтверждения.
На сервере, который Windows 2000, выполните следующие действия:
На сервере, на Windows XP или Windows Server 2003, выполните следующие действия:
Метод 4. Изменение поведения буферизации в afd.sys для неблокирующих розеток
В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения о том, как создать и восстановить реестр, щелкните следующий номер статьи, чтобы просмотреть статью в базе знаний Майкрософт: 322756 Как создать и восстановить реестр в Windows
Этот ключ реестра доступен только для Windows Server 2003 с Пакет обновления 1 и последующими пакетами служб.
Статус
Корпорация Майкрософт подтвердила, что это проблема в продуктах Майкрософт, перечисленных в разделе «Применяется к».
Ссылки
328890 Новая запись реестра для управления поведением TCP Acknowledgment (ACK) в Windows XP и Windows Server 2003
Тема: Оптимизация Windows 10 и сетевых настроек.
Опции темы
Заходим в раздел система в том же окне «Параметры» и в разделе«Уведомления и действия» делаем как на скрине( « Отображать советы по работе» тоже отключаем, если есть)
«Многозадачность» отключаем как на скрине.»
«Режим планшета», выключаем «Включать дополнительные возможности сенсорного управления Windows при использовании устройства в качестве планшета». Эта опция присутствует, если перо и сенсорный ввод доступен для ПК,остальное делаем как на скрине. »
«Питание и спящий режим» делаем всё как на скрине.
Персонализация
Дополнительно заходим в раздел «персонализации» в том же окне «Параметры» и в разделе «Цвета» деактивируем эффект прозрачности Панели задач,Пуска и Центра уведомлений. Это положительным ключом отразится на скорости работы ПК.
Специальные возможности
«Экранный диктор»отключаем как на скрине.
«Экранная лупа» отключаем.
«Клавиатура» выключаем «Включение экранной клавиатуры», это для
планшетов.
В последнем разделе «Другие параметры» отключаем первую опцию,отвечающую за воспроизведение анимации в среде Виндовс 10.
Конфиденциальность
«Общие» выключаем как на скрине.
«Фоновые приложения» как на скринах отключаем.
Обновление и безопасность
«Центр обновления Windows » отключать не советую!
«Защитник Windows » оставляем как есть, нет необходимости
использовать стороннюю Антивирусную программу.
«Для разработчиков» как на скрине.
Программы в Пуске
Плитки в Пуске расходуют системные ресурсы,и, если они не нужны, такие приложения следует деактивировать.
открывается
Службы- ставим галочку «Не отображать службы Майкрософт» иотключаем всё, кроме:
1. Видеокарты.
2. Вашегоустройства( в моём случае ASUS )
Далее, применить и ОК(ПЕРЕЗАГРУЖАЕМСЯ)
Многие знакомы со способом повышения быстродействия системы путем отключения визуальных эффектов для окон и меню.Отключаются все графические эффекты, сопровождаемые большинство действий в Проводнике, через свойства системы.
1. Панель управления.
2. Выбираем «Система».
3. Переходим в расширенные параметры системы.
4. Во вкладке «Дополнительно» нажимаем по кнопке«Быстродействие».
5. Переносим чекбокс к позиции «Обеспечение наилучшего быстродействия» или вручную убираем флажки с эффектов, которые следует деактивировать. Таким образом можно добиться повышения скорости работы компьютера/ноутбука без существенного ущерба графическому виду среды Windows 10.
Отключаем «Дамп памяти».
«Удалённый доступ» снимаем галочку как на скрине, применить.
Звук
Мизерной прибавки в скорости работы ПК можно добиться путем отключения назойливого звукового сопровождения системных событий. Вызываемапплет «Звук», где на вкладке «Звуки» выбираем схему «Без звука» и сохраняем новые настройки. Теперь Windows 10 не будет обращаться к жесткому диску для воспроизведения соответствующего аудиофайла.
Выставляем схему электропитания : » высокая производительность».
Отключаем автоматическую дефрагментацию жёстких дисков, потому что очень не удобно когда играешь, а у тебя вдруг по расписанию произошёл запуск дефрагментации и мы все беды переводим на игру, а надо всего лишь делать это вручную(там же), хотя бы один раз месяц. Делаем как на скрине.
Очистку буфера кэша записей Windows – делаем как на скринах!
Проверка диска на ошибки файловой системы
Вариант 1.Открываем проводник Windows, нажимаем правой кнопкой мыши по необходимому диску и выбираем пункт “Свойства”.
В открывшемся окне выбираем вкладку “Сервис” и запускаем проверку диска.
Вариант 2.Запускаем командную строку с правами администратора.
Сделать это можно, нажав правой кнопкой мыши по меню “Пуск” и выбрав соответствующий пункт.
Вводим команду
chkdsk C: /F /R
где, chkdsk – команда для запуска утилиты проверки диска Check Disk
C: — выбранный для проверки диск
F – параметр, задающий автоматическое исправление ошибок
R – поиск поврежденных секторов и попытка восстановления данных
Вводим «Y» и перегружаем ПК, при старте ОС которого начнётся проверка указанного диска и исправление(данный вариант лучше первого).
Останавливаем и отключаем службы:
1. KtmRm для координатора распределенных транзакций.
2. Windows Search.
3. Биометрическая служба Windows.
4. Вспомогательная служба IP.
5. Вторичный вход в систему(если вы единственный пользователь ПК).
6. Диспетчер автоматических подключений удаленного доступа.
7. Диспетчер печати(если нет принтера и сканера).
8. Диспетчер подключений удаленного доступа.
9. Интерфейс гостевой службы Hyper-V.
10. Клиент отслеживания изменившихся связей.
11. Маршрутизация и удаленный доступ.
12. Модуль поддержки NetBIOS через TCP/IP.
13. Настройка сервера удаленных рабочих столов.
14. Обнаружение SSDP.
15. Политика удаления смарт-карт.
16. Помощник по входу в учетную запись Майкрософт.
17. Прослушиватель домашней группы.
18. Распространение сертификата.
19. Расширения и уведомления для принтеров(если есть принтер- оставляем).
20. Сборщик событий Windows.
21. Сервер(если нет локалки).
22. Сетевой вход в систему(если вы не один пользователь ПК).
23. Служба Hyper-V PowerShell Direct.
24. Служба виртуализации удаленных рабочих столов Hyper-V.
25. Служба завершения работы в качестве гостя (Hyper-V).
26. Служба запросов на теневое копирование томов Hyper-V.
27. Служба запросов на теневое копирование томов Hyper-V.
28. Служба обмена данными (Hyper-V).
29. Служба общего доступа к портам Net.Tcp.
30. Служба перечисления устройств чтения смарт-карт.
31. Служба перечислителя переносных устройств.
32. Служба пульса (Hyper-V).
33. Служба сенсорной клавиатуры и панели рукописного ввода.
34. Служба синхронизации времени Hyper-V.
35. Служба уведомления о системных событиях.
36. Служба удаленного управления Windows (WS-Management).
37. Служба шифрования дисков BitLocker.
38. Смарт-карта.
39. Темы(если не пользуетесь, на Windows 7 – не отключать)
40. Удаленный реестр.
41. Узел системы диагностики.
42. Узел службы диагностики.
43. Узел универсальных PNP-устройств.
44. Центр обеспечения безопасности.
Сеть(интернет)
Командная строка от Администратора( cmd ) и вводим поочередно команды:
Все сетевые соединения обрабатываются в сетевой карте.
netsh int tcp set global chimney=enabled
Прямой доступ к кэшу NetDMA 2.0 (Direct Cache Acess).
netsh int tcp set global dca=enabled
Обмен информацией между сетевой платой ипамятью ОЗУ без участия CPU (NetDMA).
netsh int tcp set global netdma=enabled
Просто говоря заминка на маршрутизаторе,снижаем передачу (пробки на дорогах).
netsh int tcp set global ecncapability=enabled
Windows Registry Editor Version 5.00
2) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile
а)NetworkThrottlingIndex
Убирает ограничения для не мультимедийного трафика.
Рекомендуемое значение: ffffffff (шестнадцатеричное значение).
б) SystemResponsiveness
Рекомендуемое значение: 00000000 (шестнадцатеричное значение).
1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile\Tasks\G ames
а)GPU Priority «8»
б) Priority «6»
Отключение Xbox DVR с помощью редактора реестра
А) Если у вас нет аккаунта Xbox и вы не выполнили вход вприложение Xbox, вы можете отключить Xbox DVR с помощью редактора реестра.
1. Откройте редактор реестра (Пуск > regedit)
2. Перейдите к папке HKEY_CURRENT_USER\ System\ GameConfigStore
3. Задайте значение DWORD 0 для «GameDVR_Enabled»
4. Перейдите к папке HKEY_LOCAL_MACHINE\ SOFTWARE\ Policies\ Microsoft\ Windows\
5. Создайте ключ«GameDVR».
6. Создайте ключ с параметром DWORD (32 бита) и назовите его«AllowGameDVR» и задайте значение 0
7. Перезагрузите компьютер.
Настройки видеокарт в этой теме: https://cfire.mail.ru/forums/showthread.php?t=312030
Убрать ограничение пропускной способности (инет в помощь) точно также как и в Windows7.