Зменшуємо пінг - корисні статті про wow - каталог статей - портал-world of warcraft патчі, аддони,

Пуск - Виконати - вводите regedit

1. Шукайте:
HKEY_LOCAL_MACHINE # 92; SYSTEM # 92; CurrentControlSet # 92; Servises # 92; Tcpip # 92; Parameters # 92; Interfaces # 92;

Там буде кілька підпапок з ім'ям за типом.
Мотря кожне, і шукайте в якому стоїть ваш інтернетівський IP шник.

Правою кнопкою миші і додаєте DWORD параметр з ім'ям TcpAckFrequency, привласнюєте значення 1 (хоч в 10ічной хоч в 16ічной системі)
Якщо щось потім не сподобається, то виставляння значеня 2 поверне настройку за умовчанням.

2. Шукайте HKEY_LOCAL_MACHINE # 92; SOFTWARE # 92; Microsoft # 92; MSMQ # 92; Parameters

Правою кнопкою додаємо параметр DWORD c ім'ям TCPNoDelay і ставимо значення параметра 1

3. Перевантажуємо комп'ютер

Якщо починаються страшні втрати пакетів, то повертайте настройки назад.

Подібне шаманство буде інтегровано в новий патч.

Як це працює?
Значення TcpAckFrequency визначає частоту відправки TCP / IP підтверджує повідомлення.
Якщо значення дорівнює 2, TCP / IP буде відправляти підтвердження після 2 прийнятих сегментів
Якщо після прийняття 1 сегмента і відсутності другого сегмента протягом 200 мілісекунд.
Якщо значення дорівнює 3, TCP / IP відправляє підтвердження після прийому 3 сегментів,
Їли після прийому 1 або 2 сегментів і відсутності подальших сегментів протягом 200 мілісекунд.
І так далі.

Якщо вам потрібно скоротити час відповіді за рахунок видалення затримок відправки підтверджень TCP / IP, задайте це значення рівним 1.
В такому випадку TCP / IP буде негайно відправляти підтвердження для кожного сегмента.
Якщо ваші з'єднання використовуються в основному для передачі великих обсягів даних і затримка в 200 мілісекунд несуттєва,
Має сенс збільшити це значення для зниження додаткового навантаження відправки підтверджень.
Ну а якщо дрібні, такі як наші пакетики WoW то краще поставити негайне.

Параметр TCPNoDelay відключає алгоритм Nagl'e.
З алгоритму випливає, що в TCP з'єднанні може бути присутнім
Тільки один вихідний маленький сегмент, який ще не був підтверджений.
Наступні маленькі сегменти можуть бути послані тільки після того, як було отримано підтвердження.
Замість того щоб відправлятися послідовно, маленькі порції даних накопичуються
і відправляються одним TCP сегментом, коли прибуває підтвердження на перший пакет.
Краса цього алгоритму полягає в тому, що він сам налаштовує тимчасові характеристики:
Чим швидше надійде підтвердження, тим швидше будуть відправлені дані.
На повільних глобальних мережах, де необхідно зменшити кількість маленьких пакетів, відправляється менше сегментів.

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

Так що використовуючи дані настройки, ми зменшуємо реально навантаження. збільшуючи прохідність каналу і отже "зменшуємо" затримку.

Однак при цьому страждають такі речі як скачування файлів, служби торент, ДонЛоадер вова теж буде довше качати патчі.
Потім ми можемо втрачати дані (протокле TCP втрачає свою основну перевагу над UDP)