Cl flushentitypacket как исправить

#1

#2

Eskobar

#3

John.

#4

_jeka_

#5

Sergeant

#6

Eskobar

#7

+CancelSelect

1. 
   

   LOMVi
   Постоянный пользователь

   В данной теме обсуждаются игровые проблемы касающиеся:

   • большого времени отклика серверов (ping, latency, «высокий пинг»);
   • потери пакетов до серверов (loss);
   • низкой пропускная способность каналов (choke, «удушье»).

   Как посмотреть значения этих параметров:

   • в консоли пишем команду: net_graph 3
   • появляется график который и отображает значения параметров: ping, loss, choke
   • чтобы убрать график в консоли пишем команду: net_graph 0

   

   Если у вас наблюдаются подобные игровые проблемы не связанные с вашим компьютером и провайдером, то вам следует сделать следующее:

   • Скачать прикрепленный файл: cs.lightning-club.ru.zip
   • Распаковать его в в любую папку на компьютере
   • Запустить cs.lightning-club.ru.cmd
   • Скрипт будет выполняться от 3 до 10 минут!
   • После выполнения в той же папке у вас будет создан файл cs.lightning-club.ru.txt с результатами работы
   • Полученный файл отправить на support@lightning-club.ru
   • ОБЯЗАТЕЛЬНО: в теме письма указать слово ПИНГ, а в самом письме Ваш город и название провайдера.

   По всем вопросам технической поддержки наших серверов обращайтесь на e-mail: support@lightning-club.ru

   (с)ViP.Predator

   Вложения:

   Последнее редактирование модератором: 11 янв 2014

2. 
   

   LOMVi
   Постоянный пользователь

   Вступление

   Решился вот накатать статейку, потому что вижу довольно много тем в стиле «аааа! на серве все лагает! че делать!?», в которых даются советы без объяснения причин. В итоге проблема может быть и решается, но недопонимание о причинах все равно остается. После прочтения данной статьи оно должно исчезнуть.
   Итак, лагом в общем случае можно назвать все внутри-компьютерные явления, которые мешают нормальной игре. Примеры: «слайд-шоу», зависание картинки, зависание игровых объектов. Но соседа с перфоратором к лагам отнести нельзя, хотя играть он мешает.

   ПРИЧИНЫ ЛАГОВ

   Все причины лагов можно разделить на:

   1. Проблемы на компьютере игрока — их в силах решить сам игрок;
   2. Проблемы на канале связи между компьютером игрока и сервером;
   3. Проблемы на сервере.

   СПИСОК ТЕРМИНОВ
   
   Ниже рассмотрим все это подробнее, но для начала список терминов, используемых в статье:

   • HL, Half-Life — в статье используется как название движка (но не игры про Гордона Фримена!). Данные из статьи применимы ко всем модам, созданным на этом движке, в том числе и для Counter-Strike.
   • Клиент — это программа (Half-Life), запущенная на компьютере игрока, которая обменивается данными с сервером и рисует картинку игрового мира.
   • HLDS, Half-Life Dedicated Server -это программа такая, собственно серверная часть для Half-Life.
   • Сервер — Компьютер, на котором запускается HLDS
   • CVar, он же Console Variable — переменная, использующаяся в Half-Lfe, изменяющая какие-либо параметры игры. Может быть изменена пользователем из консоли (отсюда и название). CVar используются как на клиенте, так и в HLDS. CVar, влияющие только на серверную часть, имеют префикс sv_ (примеры — sv_gravity, sv_clienttrace); CVar, влияющие только на клиент имеют префикс cl_ (cl_lw, cl_lc, cl_updaterate).

   ПЕРЕМЕННЫЕ (CVARS)

   Клиентские:

   • cl_updaterate — количество пакетов в секунду, которое клиент хочет получать от сервера (именно хочет, но не факт что получит), 1/сек
   • cl_rate — исходящая полоса пропускание клиента (для данных от клиента к серву), байт/сек,
   • то есть максимальная скорость передачи данных к серверу
   • rate — входящая полоса пропускания клиента (для данных от сервера к клиенту), байт/сек, или максимальная скорость передачи данных к клиенту
   • net_graph — определяет тип отображения статистики по сетевому подключению. может принимать значения от 0 до 3 (об это позже)

   Серверные:

   • sv_maxrate — максимальная скорость отдачи данных для одного клиента, байт/сек
   • sv_minrate — минимальная скорость отдачи данных для одного клиента, байт/сек
   • sv_maxupdaterate — максимальное количество пакетов в секунду, которое может быть передано одному клиенту.
   • sv_minupdaterate — минимальное количество пакетов в секунду, которое может быть передано одному клиенту.
   • sys_ticrate — определяет максимальное количество кадров, которые сервер может обсчитать за секунду. В HLDS используется значение 1000/sys_ticrate (это в миллисекнудах) как интервал перерыва между обсчетом кадров.

   Матчасть

   КАК HLDS КОНТРОЛИРУЕТ ПОТОК ДАННЫХ К КЛИЕНТАМ

   Отдача данных в HLDS контролируется отдельно для каждого клиента, на основе двух факторов:

   1. количество пакетов в секнуду, передаваемых клиенту, назовем это значение updrate
   2. максимальная скорость передачи к клиенту, назовем это значение cmrate.

   I. Исходными данными для определения updrate служат три переменные — это клиентская cl_updaterate, и серверные sv_maxupdaterate и sv_minupdaterate. Алгоритм определения updrate можно записать так:

   updrate := cl_updaterate;if updaterate > sv_maxupdaterate then update := sv_maxupdaterate;if updaterate < sv_minupdaterate then updrate := sv_minupdaterate;

   Видно, что по умолчанию updrate равен клиентскому значению. Однако оно не должно вылазить за пределы максимальных и минимальных значений, определенных в HLDS.

   Вот несколько примеров для лучшего понимания:

   cl_updaterate=30, sv_minupdaterate=20, sv_maxupdaterate=60. В Этом случае клиент будет получать от сервера 30 пакетов в секунду, т.е. что клиент хотел, то и получил.
   cl_updaterate=100, sv_minupdaterate=20, sv_maxupdaterate=60. В Этом случае клиент будет получать от сервера 60 пакетов в секунду, т.к. значение уперлось в верхний порог.
   cl_updaterate=10, sv_minupdaterate=20, sv_maxupdaterate=60. В Этом случае клиент будет получать от сервера 20 пакетов в секунду, тк значение уперлось в нижний порог.​

   II. Исходными данными для cmrate служат значения клиентской переменной rate и серверных sv_maxrate и sv_minrate. Алгоритм определения точно такой же, как и у updrate, то есть по умолчанию cmrate = rate, однако если значения вылазит за пределы sv_minrate или sv_maxrate, то оно ограничивается.

   КАК HLDS ФОРМИРУЕТ СЕТЕВЫЕ ПАКЕТЫ
   
   При работе HLDS все данные, которые должны быть посланы клиенту, складываются в отдельный буфер (он свой для каждого клиента), где и ждут момента, когда подойдет время их пересылки. Как только время подошло, данные начинаются записываться в пакет. На размер пакета накладывается ограничение по cmrate, чтобы не перегрузить полосу, отведенную клиенту. Максимальный размер пакета, связанный с этим ограничением, может быть вычислен как cmrate/updrate, то есть максимальная скорость делится на количество пакетов в секунду. Но что будет, если данных сервер сгенерировал больше, чем может отправить? Тогда все просто — в пакет записываются только данные, которые укладываются в максимальный лимит, остальные остаются ждать следующей пересылки. Так же в пакет дописывается однобайтовое сообщение svc_choke, которое сигнализирует о том, что HLDS не смог послать все данные, которые сгенерировал. Да, эти данные придут к клиенту в следующем пакете, однако придут они уже с задержкой. А если очередь данных на HLDS разрастается и никогда не заканчивается, то на клиенте можно наблюдать нехилый такой рост пинга, и значение choke = 99 (его можно посмотреть в net_graph 3).
   Отдельным пунктом стоит отметить то, что проверка на размер пакета осуществляется только если сервер работает в Internet режиме (sv_lan 0). При sv_lan 1 эта проверка отключается. Это может быть причиной появления лагов при переводе HLDS на sv_lan 0 при ненастроенных sv_maxrate/sv_minrate.
   

   ПРОВОДИМ ДИАГНОСТИКУ

   Итак, чтобы избавиться от лагов, надо знать их причину. А причину нам поможет узнать очень хорошее встроенное в HL средство под названием net_graph, которе отображает в реальном времени информацию, связанную с передачей данных. Имеется 3 режима отображения, мы будем пользоваться первым (net_graph 1).
   Для начала дадим описание того, что там вообще отображается:

   

   • 1 строчка — интервал десинхронизации (грубо говоря — пинг), значение cl_updaterate
   • 2 строчка — информация о данных от сервера: текущий размер пакета и средняя скорость приема
   • 3 строчка — информация о данных к серверу: текущий размер пакета и средняя скорость отдачи
   • 4 строчка — график данных от сервера. Каждая точка — входящий пакет, высота точек показывает задержку (пинг), чем выше точка, чем больше задержка. Сами точки могут быть 3-х цветов: зеленые — нормальный пакет, пришел вовремя, нигде не задержался, желтый — пакет с маркером choke, значит сервер не смог отправить все данные из-за политики рейтов; красный — пакет потерялся на просторах интернета. Количество loss (потерянных паетов) и choke пакетов можно так же увидеть в цифрах режиме net_graph 3. Значение, отображаемые там нужно понимать так — сколько пакетов из последних 100 было потеряно(loss) или переполнено(choke).
   • 5 строчка — текущее значение cl_cmdratre
   • 6 строчка — два графика (хотя трудно их там разглядеть). Обновляются они синхронно, каждый столбец соответствует одному кадру, который отрисовывает клиент.

   Первый график- высотой в один пиксель в самой нижней части. Содержит красные точки. Ими помечаются кадры, в которые не были отправлены cmd пакеты к серверу (можно сказать, аналог choke для клиента, то есть у клиента есть данные для отправки, но отправить он их не может, так как время отправки еще не подошло). В случае, если пакеты отправляются на сервер после отрисовки каждого кадра, графика вообще не видно.

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

   ПРИМЕРЫ, ОПИСАНИЯ И РЕШЕНИЯ

   А теперь примеры проблем с картинками и описанием. Ниже набор из 6-ти скриншотов + описание к ним

   

   1. Симптомы — слайд-шоу, низкий фпс. Причины: железу на клиенте пора на помойку, либо что-то еще нехило кушает процессорное время (может антивирус, или наоборот какая-то вирусня). Решение: Найти и истребить объект, использующий ЦП, либо бежать в магазин за новым компутером.
   2. Видим красные точечки на зеленом графике — потеря пакетов. Это не лучший скрин для демонстрации, но ничего другого нет к сожалению. Симптомы — рывки игроков во время игры, задержка стрельбы или других действий. Особенно хорошо проявляется, когда теряется несколько пакетов подряд. Решение: Единого способа нет, т к причина может быть независящей от вас (может пьяный одмин за кабель запнулся). Что можно сделать — вырубить все, что использует сеть, особенно торренты и закачки. Можно попробовать собрать диагностику ping/traceroute и отправить в саппорт провайдера
   3. А тут у нас фриз на компьютере клиента. Симптомы — внезапомное «замирание» игры на 200-300мсек, после чего нормальное продолжение. На нетграфе сопровождается подскоком зеленого графика «под потолок» (на скрине видно два фриза с небольшим интервалом), при этом на нижнем графике нет никаких отклонений. Причины — в основном связаны с драйверами или железом. Фриз, который можно лицезреть на скрине был вызван «умным» поведением винчестера — после 5-6 секнуд неактивности он паркует блок головок, а при при попытке чтения чего-либо распарковывает их, при этом вся система ненадолго зависает. Решения — попробовать поставить «рядом» чистую ОС и посмотреть, будут ли фризы на ней. Если будут — проблема с железом, ищем виновника последовательной заменой комплектующих. Если же полет нормальный — дело было в каком-то шибко умном драйвере. Так же может иметь конфликт железо-железо, либо железо-драйвер. В общем, единый путь решения найти трудно.
   4. Самая часто встречающаяся сейчас проблема — choke, желтизна на графике, который должен быть зеленым. Симптомы — рост пинга при большом количестве игроков, либо на картах, где видно одновременно много объектов, задержка стрельбы, может быть видно передвижение других игроков и объектов рывками. Причина: Сервер генерирует больше данных, чем может передать. Решение: Нужно увеличивать скорость, выделяемую клиенту. Ставим rate побольше (например 300000) и смотрим, что произойдет. Если желтизна исчезла — можете поздравить себя с решением проблемы. Если нет — пытаемся достучаться админу сервера. Если админом являйтесь вы, то тогда ставим в HLDS sv_maxrate побольше (100000 например). Можно так же поднять и sv_minrate — это поможет игрокам с дефолтным конфигом (там вроде стоит rate 6000) избежать choke-ов и лагов.
   5. Тут мы наблюдаем явную гребенку на нижнем графике — это означает что клинет получает данные через слишком большие интервалы времени. В игре может выражаться небольшим ростом пинга, небольшим подергиванием объектов, игроков. Причины: низкий cl_updaterate или очень маленький sv_maxupdaterate на серверное стороне. Лечится увеличением значений этих переменных. Так же такое поведение может вызываться очень низким серверным ФПС (< 50). Решается разгрузкой процессора на сервере, либо поднятием значения sys_ticrate (если он имеет малое значение, т е < 100). Можно еще поставить плагины для увеличения серверного фпс, только при перегруженном ЦП они не спасут.
   6. Здесь можно лицезреть фриз на серверной стороне — был очень большой перерыв между обработками кадров на сервере. На нетграфе выражается подскоком на нижнего графике десинхронизации, при этом с доставкой пакетов проблем не было (верхний график в норме).

   ПРИЧИНЫ

   Причин несколько:

   1. обычно связана с высокой загрузкой диска на сервере, когда HLDS пытается что-либо прочитать — происходит задержка.
   2. может происходить из-за блокирующих запросов в перегруженную субд. Решение — переходим на неблокирующие (threaded) запросы, правда тут без переписывания кода плагинов не обойтись
   3. низкий приоритет, данный HLDS. Если на сервере нашелся процесс с намного более высоким приоритетом, чем HLDS, при этом он загрузил весь (все) ЦП, то HLDS отправляется курить на это время.

   Автор: berq
   Источник: hlds.us

3. 
   

   zub.zer0
   Постоянный пользователь
   CS Админ

   

   Заметил лаг сервера. по net_graph 2 переодически белые точки, что на рисунке выше, у меня в 10! раз выше почти вверху моего монитора О_О

   из-за чего со стрельбой на сервере у меня в последний месяц, вообще беда… ранее до поломки сервера и его востановления, было ровно-гладко почти как на ЛАНе…

4. Первый пост обновлен!!!
   Желательно выполнить рекомендации из первого поста, всем у кого проблемы с пингом, лагами и т.д. до 15 января 2014 г.
   Не забудьте писать город, провайдера и правильно оформлять тему письма. Все что наберется отдаем провайдеру и он комплексно решает проблему.
   Все кто не успеет прислать извиняйте…

5. 
   

   Pavel
   Постоянный пользователь

   Проблема: скачет пинг, лаги.

   Город: Челябинск
   Провайдер: ИнтерСвязь

   Вложения:

   Последнее редактирование модератором: 11 янв 2014

6. Отправил на почту, но на всякий случай скину еще и сюда.

   Люберцы
   Искра Телеком

   Вложения:
7. 
   

   4yDuk
   Постоянный пользователь

   типа похвалился?))))

8. 
   

   4yDuk
   Постоянный пользователь

   а вот моя печалька

   Вложения:
9. 
   

   4yDuk
   Постоянный пользователь

   хотя ет еще не печалька,с таким пингом я Сталкера в хлам рву))))))))

10. 
    

    4yDuk
    Постоянный пользователь

    а это печалька…

    Вложения:
11. 
    

    4yDuk
    Постоянный пользователь

    а это полный ппц

    Вложения:
12. 
    

    zub.zer0
    Постоянный пользователь
    CS Админ

    100 / 100 = 100%
    Я твой пинг кс шатал (с) naukanet

13. 

    
    Kly111ka и 4yDuk нравится это.
    

14. 
    

    4yDuk
    Постоянный пользователь

    я тож буду улыбаться,когда кто-нить там поближе маленький теракт на их железе сделает…

15. 
    

    zub.zer0
    Постоянный пользователь
    CS Админ

    Вот еще один интересный гайд:

    http://www.counter-strike.cn.ua/forum/index.php?showtopic=1003

    После проделанных мною 1 и 2, пинг в КС сравнялся с самой командой ping.
    и вместо 18-20, стал 13-15

    И кстати, если сервер на windows — сделайте точно такую-же оптимизацию
    А еще можно поколдовать с MTU на интерфейсе — дабы не делать фрагментацию пакетов на маршруте до игроков

    Последнее редактирование: 26 янв 2014

16. 
    

    4yDuk
    Постоянный пользователь

17. Пинг скачет
    Город: Уфа
    Провайдер:http://www.bashtel.ru

    Вложения:

18. Полученный файл отправить на support@lightning-club.ru
    ОБЯЗАТЕЛЬНО: в теме письма указать слово ПИНГ, а в самом письме Ваш город и название провайдера.

19. 
    

    yurKa
    Постоянный пользователь

    Я отправлял такой файл недавно. Пинг 50 на наш серв,на украинские серваки пинг 45

20. пинг 90-100 уже 2-ой месяц…

    Вложения:

    • 

21. В первом посте описано как сформировать правильный файл и куда его отправить.

22. 
    

    easy
    Главный администратор
    Команда форума

    в последнее время очень часто зависаю и вижу надпись в правом верхнем углу «cl_flushentitypacket» затем меня выкидывает из игры. «Tracert» показывает проблемы то на втором-третьем шаге, то на 4-5. Коннект нестабильно плох. Содержимое файла *.txt после тестирования сети тоже все время разное. Как пример приложенные файлы. В файле PING.txt видно что проблема плавающая.

    Вложения:

    • PING.txt

      Размер файла:

      7,2 КБ

      Просмотров:

      7

    Последнее редактирование: 24 апр 2014

23. Основные проблемы на узле провайдера: static.donpac.ru, это не считая пипец с твоим роутером

    Но то, что до роутера есть такие проблемы — это вообще ненормально…
    Проверь нет ли нагрузки на сеть… фоновые торренты и т.д.
    Если связь через WiFi нету ли источников помех, много ли клиентов WiFi, ну и конечно нагрузка на эту сеть

24. 
    

    zub.zer0
    Постоянный пользователь
    CS Админ

    Более 2мс до роутера (192.168.1.1) уже говорит о проблемности еще в этом узле. возможно не в самом роутере, а в ПК

25. 
    

    easy
    Главный администратор
    Команда форума

    Да, связь через вай-фай. Недавно купил новый роутер (коннект со старым периодически пропадал — комп терял подключение к нему). Проблема с «cl_flushentitypacket» сохранилась после переустановки Win7. Торрентов нет. В сети одновременно не более 2 единиц (жена на планшете сёрфит без закачек значительных объемов).
    Как проверить наличиеотсутствие помех?