• Автор теми Автор теми wck
  • Дата створення Дата створення

wck

Статус: Офлайн
Реєстрація: 31.07.2008
Повідом.: 422
В общем я являюсь так сказать, не ярым, но фанатом ММОРПГ, и предмет лагов там на 1 месте, смотрел демку типа одного - увидел как он показывает редактирование сего ключа в реестре:
Код:
1) Determine your IP (ipconfig or similar) 
2) Run Regedit 
3) Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces 
4) Determine which interface is for your IP. The correct interface will have a DhcpIPAddress set to your current IP. 
5) Right-click on the interface and select New->DWORD 
6) Set the name to TcpAckFrequency (case sensitive) 
7) Set to a decimal value of "1" 
8) Save 
9) Restart your computer
В резалте уменьшается пинг, и задержка как таковая пропадает Оо (но без объяснений что он этим сделал). Влияет это как я понял только на соединения по TCP протоколу. У меня вопрос, если ли кто может объяснить в 2х словах на что влияет добавление этого ключа/редактирование Посилання видалено пишет что добавление этого ключа не приводит ни к какому эффекту - почему? ведь у меня получилось снизить пинг и избавиться от задержки . . не осилил я в общем эти разъяснения хоть и с инглишем дружу (: (Посилання видалено помогите пжлст, если ли у кого нибуть возможность трактовать иначе, непонятно мне как оно работает ):

ЗЫ вот еще накопал, тоже ключик помогает бороться с большими пингами - работает в связке с TcpAckFrequency:
Код:
TCPNoDelay

Ищем там:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters

Правой кнопкой справа на чистом поле, там - создать новый DWORD, 

называем его TCPNoDelay, Жмем правой кнопкой, там Изменить - ставим value - 1.
 
хмы.. Фикс kb815230 как раз и было посвящено исправлению того самого "ничего не даёт" в XP SP1 (в числе прочих ошибок в стеке). И если оно (фикс) у тебя есть (а ошибка была исправлена в период ДО sp2, так что 100% есть) - обязано давать.
А что оно вообще делает.. ты что, не осилил найти описание Посилання видалено ? :)
SUMMARY
TcpAckFrequency is a new registry entry in Microsoft Windows XP and Microsoft Windows Server 2003 that determines the number of TCP acknowledgments (ACKs) that will be outstanding before the delayed ACK timer is ignored.
MORE INFORMATION
As specified in RFC 1122, TCP uses delayed acknowledgments to reduce the number of packets that are sent on the media. Instead of sending an acknowledgment for each TCP segment received, TCP in Windows 2000 and later takes a common approach to implementing delayed acknowledgments. As data is received by TCP on a particular connection, it sends an acknowledgment back only if one of the following conditions is true:
• No acknowledgment was sent for the previous segment received.
• A segment is received, but no other segment arrives within 200 milliseconds for that connection.

Typically, an acknowledgment is sent for every other TCP segment that is received on a connection unless the delayed ACK timer (200 milliseconds) expires. You can adjust the delayed ACK timer by editing the following registry entry.
[....]

If you set the value to 1, every packet is acknowledged immediately because there is only one outstanding TCP ACK as a segment is just received. The value of 0 (zero) is not valid and is treated as the default, 2. The only time the ACK number is 0 is when a segment is not received and the host is not going to acknowledge the data.
 
А теперь по русски и простыми словами :)

В самом общем случае ТЦП посылает на каждый принятый пакет квитанцию о получении - именно этим механизмом обеспечивается гарантированность доставки пакетов (например нет квитанции - отправитель посылает пакет еще раз и т.д.)
Теперь прикинь, что таких квитанций в общем случае приходится посылать очень много забивая обратный канал. Была придумана фича, что будем посылать квитанцию не на один пакет, а на несколько (на сколько именно - для этого тоже есть ключ в реестре ;) ). Фича хорошая, но представь ситуацию: задано посылать квитанцию на 5 пакетов сразу. Однако в какой-то момент от отправителя получено 4 пакета и все, больше нету, потому что отправлять больше ничего не надо. Формально квитанцию отправлять рано - ждем пятый пакет до кучи, а его все нет и может не быть вовсе. Чтобы не попасть в такую ситуацию, было введено правило, что "да, мы будем посылать квитанцию на заданное число пакетов сразу, но если за определенное время мы не насобирали нужное кл-во пакетов для отправки квитанции - мы ее отправим на столько пакетов, сколько есть".
Вот это определенное время - и есть твой параметр.
 
Ага, пожалуйста если не учесть что я чуток перепутал :)
Вдумчиво прочел твой вопрос :)
Все что я написал - правильно, однако я в тексте упоминал еще ключ в реестре, который определяет кл-во пакетов, на которые будет посылаться одна квитанция. Так вот, твой параметр - и есть
тот ключ :)
А параметр TcpDelAckTicks как раз определяет тот самый таймаут, по истечении которого и будет послана квитанция на столько пакетов, сколько есть.

Поставив 1 (вместо по умолчанию 2) - ты на самом деле загрузил обратный канал - вместо квитанции на 2 пакета отправляется квитанция на каждый пакет. Но при этом пинг (если разговор идет о ТЦП-пингах или иной логической организации измерения времени "запрос-ответ" через ТЦП) действительно уменьшается, потому что нет или ожидания второго пакета или дефолтовой задержки в 200 мс перед отправкой квитанции.
 
Ага, пожалуйста если не учесть что я чуток перепутал :)
Вдумчиво прочел твой вопрос :)
Все что я написал - правильно, однако я в тексте упоминал еще ключ в реестре, который определяет кл-во пакетов, на которые будет посылаться одна квитанция. Так вот, твой параметр - и есть
тот ключ :)
А параметр TcpDelAckTicks как раз определяет тот самый таймаут, по истечении которого и будет послана квитанция на столько пакетов, сколько есть.

Поставив 1 (вместо по умолчанию 2) - ты на самом деле загрузил обратный канал - вместо квитанции на 2 пакета отправляется квитанция на каждый пакет. Но при этом пинг (если разговор идет о ТЦП-пингах или иной логической организации измерения времени "запрос-ответ" через ТЦП) действительно уменьшается, потому что нет или ожидания второго пакета или дефолтовой задержки в 200 мс перед отправкой квитанции.

А почему TcpDelAckTicks влияет на пинг? Коим боком пинг к ТСП?
 
Исходя из ваших рассуждений выходит, что пинг без этого ключа в реестре никак не может быть меньше 200 мс. Однако...

А почему TcpDelAckTicks влияет на пинг? Коим боком пинг к ТСП?
Если вы, господа, читали внимательно - то там есть слова:
...при этом пинг (если разговор идет о ТЦП-пингах или иной логической организации измерения времени "запрос-ответ" через ТЦП)...
Кто не знает о чем я - гуглит на тему tcpping.exe.
Об классическом ICMP там нет ни слова. Если уменьшился классический пинг - то хз почему. Вариантов много, например более частая отправка квитанций повлияла на резервирование полосы на роутере.

Кроме того я например не нашел информации о влиянии/не влиянии этих ключей на OOB-данные (out of band).
 
Назад
Зверху Знизу