Для тех у кого высокий пинг

[Loki™]

Скачать и установить

http://depositfiles.com/files/phuqj1cxw

[Merovingen]

Сам пробовал?

[Loki™]

А как ты думаешь?

Спешл фор IliaDN:

вот из-за таких глупых вопросов я и не люблю что-либо выкладывать на форуме

Изменено 24 февраля, 2010 пользователем Loki™

[ХабрХабр]

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

Кстати говоря, можно также отключить Nagle Algorithm так называемый

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters

Создаем там DWORD - "TCPNoDelay"

Ставим его значение в единичку.

 

То что осуществлено в данном файлике (том, который выложил автор темы) вручную можно сделать так:

При помощи меню "Пуск/Выполнить..." Запустите программу редактирования реестра Windows regedit.exe

Найдите в дереве (левая часть окна) ключ реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\Interfaces\

Дочерними элементами этого ключа будет несколько ключей вида {7DBA6DCA-FFE8-4002-A28F-4D2B57AE8383}

Просмотрите их все. Тот, который нам нужен, содержит массу настроек и в качестве одного из значений содержит IP адрес вашего компьютера

Кликните правой кнопкой мыши по свободном пространству в правой части окна. Появиться меню, в котором надо выбрать пункт "Создать/Параметр DWORD"

Появится новый параметр, который назовите "TcpAckFrequency". Кликните правой клавишей на созданном параметре и выберите пункт меню "Изменить" (Параметр должен быть типа DWORD)

В открывшемся окне введите значение 1

Изменено 24 февраля, 2010 пользователем ХабрХабр

[ХабрХабр]

Теоретически параметр TcpAckFrequency можно сделать и больше если у вас современная сетевуха.

Кроме того еще можно сделать так:

WIN+R ("Пуск" - "Выполнить")

gpedit.msc (открыть компонент "Групповая политика")

Политика "Локальный компьютер"

"Административные шаблоны" - "Сеть" - "Диспетчер пакетов QoS"

"Ограничить резервируемую пропускную способность" - по умолчанию там "20", а нужно установить "0"

[Hakami]

Установил) Ща посмотрю изменения будут или нет)

[Hakami]

Так-с, заценил. Лагать стало меньше процентов на 20 я думаю. Автору спс

[Sensei]

http://forum.4game.ru/showthread.php?t=23825

[Merovingen]

  Loki™ сказал:

А как ты думаешь?

Спешл фор IliaDN:

вот из-за таких глупых вопросов я и не люблю что-либо выкладывать на форуме

 

Такие глупые вопросы задаются из-за глупо созданных тем.

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

 

И попроще будь, а то перец такой, гонором прямо за километр несёт, что в кланчате, что на форуме.

 

P.S. Не было бы группы Айон, тебя бы вообще добрые модеры как бота забанили бы.

[Loki™]

Мер, да бань ё мазай. Что-то от тебя в последнее время много бла-бла слышно

 

И еще... назвать это программой, да еще и софтом у меня язык не поворачивается. Я бы назвал это аддоном.

Изменено 24 февраля, 2010 пользователем Loki™

[Last_Exile]

Как уже писали ранее в предыдущих темах, такой метод помогает, но по большей части только визуально, ибо из-за данного метода растут потери пакетов, возможно даже наоборот, ухудшение качества связи, так что не забывайте делать бекапы =)

[Merovingen]

  Loki™ сказал:

Мер, да бань ё мазай. Что-то от тебя в последнее время много бла-бла слышно

 

И еще... назвать это программой, да еще и софтом у меня язык не поворачивается. Я бы назвал это аддоном.

 

В том-то и дело, что непонятно, что это, и каков принцип действия

Это не бла-бла, это ответ на твой необоснованный агр.

[ХабрХабр]

  Last_Exile сказал:

Как уже писали ранее в предыдущих темах, такой метод помогает, но по большей части только визуально, ибо из-за данного метода растут потери пакетов, возможно даже наоборот, ухудшение качества связи, так что не забывайте делать бекапы =)

Потерь из-за этого возникнуть не может (в большинстве случаев). Данный фикс по сути - повышение частоты опроса сокета на твоем железе и задержек при отправлении подтверждений, к примеру если установить большое значение tcpackfrequency - то из проткола tcp можно получить некое подобие udp, но при текущих величинах каналов связи это не критично. Потери (в основном) в нашем случае возникают из - за перегрузки центральных узлов провайдеров (так называемых трафик шейперах). В случае с инновой это потери на узлах Ростелеком.

Кстати весьма показательно, что на мой тикет к Иннове, в котором я тестирую канал с 3-х разных провайдеров и привожу им пинги и трасировки, которые явно показывают проблему на магистрали Ростелекома, их сапорт отвечает мне - попробуйте в реестре пофиксить данный параметр. То есть люди даже не понимают что такое потери и откуда они берутся. Имхо это весьма плачевно.

Изменено 25 февраля, 2010 пользователем ХабрХабр

[Гость IliaDN]

Гонора у Басана и прямь бывает многовато...

Темку можно было оформить получше, хорошее правило есть - "делай качественно, либо не делай совсем".

В целом за топик спасибо и отдельное спасибо ХабруХабру за разжевывание че да как тут.

[Last_Exile]

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

[Злой]

Есть еще по теме лагов материал на гохе

http://forums.goha.ru/showthread.php?t=323531

Может кому пригодится =-)

[ХабрХабр]

  Last_Exile сказал:

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

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

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

Изменено 25 февраля, 2010 пользователем ХабрХабр

[ХабрХабр]

Кстати по поводу опять же высокого пинга и появившегося сообщения о торренте при запуске игры, кому интересно - можете почитать тут - http://rutracker.org/forum/viewtopic.php?t...w=newest#newest

[Last_Exile]

ХабрХабр, Так в том то и дело, что если ждать ответа, то при условии недохода 1го пакета, высылается второй такой же, а без ожидания - сразу идет следующий =)

[ХабрХабр]

  Last_Exile сказал:

ХабрХабр, Так в том то и дело, что если ждать ответа, то при условии недохода 1го пакета, высылается второй такой же, а без ожидания - сразу идет следующий =)

И? Где из этого факта образуются потери пакетов?

Отлично, представим себе взаимодействие онлайн игры и тсп/ип.

Я бегу, отправляются пакетики, ответы приходят, все окей. Потом бац, пакет или несколько пакетов потерялися. У тебя в игре появляется фриз/лаг, либо ты бежишь дальше. Что происходит дальше?

1) ждем ответа, ответ не приходит, стек тсп посылает пакет снова, далее рано или поздно он приходит. В зависимости от величины времени без связи - тебя либо дропает, либо когда все же сервер синхронизируется с клиентом - откидывает назад.

Причем! Ключ TcpAckFrequency задает частоту следования пакетов подтверждения о принятии данных. Т.е. это параметр, который грубо говоря, влияет на объем буфера квитирования пакетов на твоем сокете. На потери на сети он никаким абсолютно образом не влияет.

Если у тебя потери на узлах провайдера нулевые, то пакет тебе вернется. А если они есть, то они есть и что бы ты там у себя в реестре не правил - они все равно будут.

Еще раз. При текущих величинах каналов и адекватных величинах tcpackfrequency не может повлиять на потери пакетов. Это факт.

Изменено 26 февраля, 2010 пользователем ХабрХабр

[Glok]

Хабр

взрывает мне мозг

[ХабрХабр]

Мне каждый день взрывают мозг абоненты АКАДО своими администраторскими поползновениями в письменной форме по мылу, я ж не жалуюсь )

Изменено 26 февраля, 2010 пользователем ХабрХабр

[Last_Exile]

ХабрХабр,

  Цитата

Если комуто интересно почему это работает :

 

Значение TcpAckFrequency определяет частоту отправки TCP/IP подтверждающего сообщения.

Если значение равно 2, TCP/IP будет отправлять подтверждение после 2 принятых сегментов или после принятия 1 сегмента и отсутствия второго сегмента на протяжении 200 миллисекунд.

Если значение равно 3, TCP/IP отправляет подтверждение после приема 3 сегментов, или после приема 1 или 2 сегментов и отсутствии последующих сегментов на протяжении 200 миллисекунд.

И так далее.

 

Если вам требуется сократить время ответа за счет удаления задержек отправки подтверждений TCP/IP, задайте это значение равным 1. В таком случае TCP/IP будет немедленно отправлять подтверждение для каждого сегмента. Если ваши соединения используются в основном для передачи крупных объемов данных и задержка в 200 миллисекунд несущественна, имеет смысл увеличить это значение для снижения дополнительной нагрузки отправки подтверждений. Ну а если мелкие, такие как наши пакетики ВоВ =)) то лучше поставить немедленное.

 

Параметр TCPNoDelay отключает алгоритм Nagl'e

Из алгоритма следует, что в TCP соединении может присутствовать только один исходящий маленький сегмент, который еще не был подтвержден. Следующие маленькие сегменты могут быть посланы только после того, как было получено подтверждение. Вместо того чтобы отправляться последовательно, маленькие порции данных накапливаются и отправляются одним TCP сегментом, когда прибывает подтверждение на первый пакет. Красота этого алгоритма заключается в том, что он сам настраивает временные характеристики: чем быстрее придет подтверждение, тем быстрее будут отправлены данные. В медленных глобальных сетях, где необходимо уменьшить количество маленьких пакетов, отправляется меньше сегментов.

 

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

[ХабрХабр]

"Значение TcpAckFrequency определяет частоту отправки TCP/IP подтверждающего сообщения.

Если значение равно 2, TCP/IP будет отправлять подтверждение после 2 принятых сегментов или после принятия 1 сегмента и отсутствия второго сегмента на протяжении 200 миллисекунд.

Если значение равно 3, TCP/IP отправляет подтверждение после приема 3 сегментов, или после приема 1 или 2 сегментов и отсутствии последующих сегментов на протяжении 200 миллисекунд.

И так далее."

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

[Soulles]

позновательно... правда мозги закипели..))