- Регистрация
- 8 Июн 2017
- Сообщения
- 1.595
- Симпатии
- 571
- Пол
- Мужской
Всем привет! Решил восстановить данную статью)
Автор статьи: gudaus
Рейты - общее название для параметров, определяющих частоту и объём обмена информации сервера с клиентом. Существует ряд причин, по которым игра на сервере может быть некомфортной для клиента, то есть с лагами. Это:
Настройка рейтов - дело для каждого сервера индивидуальное, зависящие от железа, канала, билда, нагруженности, так что искать некие "оптимальные" в интернете - занятие интересное, но, увы, малополезное. Лучше это сделать самому по следующим принципам:
Под rate имеется в виду клиентский rate. То есть что происходит? В начале HLDS смотрит на maxrate. Если клиентский выше, то понижаем до серверного, если ниже - оставляем как есть. Затем HLDS смотрит на minrate. Если клиентский выше серверного, то оставляем всё как есть, а если клиентский ниже серверного, то приравниваем клиентский к серверному. Вот и получалось на билдах 5***, что клиентский rate всегда ниже, чем серверный(100 000), и принудительно выставлялось значение 100 000. На билдах 6*** максимальное значение sv_maxrate повысили до 100 000, и эта хитрость стала бессмысленной.
Заходим в server.cfg, сперва выставляем всё по максимуму.
Для билдов 5*** это
Для билдов 6*** это
Далее анализируем поведение сервера. Заходим в игру, включаем в консоли график нагрузки (net_graph 0/1/2/3), играем и параллельно смотрим на выданные в нём значения.
Надеюсь вам пригодится! В свое время статья мне очень помогла!
От Себя хотелось бы еще добавить вот такой мануал ... автор: berq!
Решение: Найти и истребить объект, использующий ЦП, либо бежать в магазин за новым компутером.
2. Видим красные точечки на зеленом графике - потеря пакетов. Это не лучший скрин для демонстрации, но ничего другого нет к сожалению. Симптомы - рывки игроков во время игры, задержка стрельбы или других действий. Особенно хорошо проявляется, когда теряется несколько пакетов подряд.
Решение: Единого способа нет, т к причина может быть независящей от вас (может пьяный одмин за кабель запнулся). Что можно сделать - вырубить все, что использует сеть, особенно торренты и закачки. Можно попробовать собрать диагностику ping/traceroute и отправить в саппорт провайдера
3. А тут у нас фриз на компьютере клиента. Симптомы - внезапомное "замирание" игры на 200-300мсек, после чего нормальное продолжение. На нетграфе сопровождается подскоком зеленого графика "под потолок" (на скрине видно два фриза с небольшим интервалом), при этом на нижнем графике нет никаких отклонений. Причины - в основном связаны с драйверами или железом. Фриз, который можно лицезреть на скрине был вызван "умным" поведением винчестера - после 5-6 секнуд неактивности он паркует блок головок, а при при попытке чтения чего-либо распарковывает их, при этом вся система ненадолго зависает.
Решения - попробовать поставить "рядом" чистую ОС и посмотреть, будут ли фризы на ней. Если будут - проблема с железом, ищем виновника последовательной заменой комплектующих. Если же полет нормальный - дело было в каком-то шибко умном драйвере. Так же может иметь конфликт железо-железо, либо железо-драйвер. В общем, единый путь решения найти трудно.
4. Самая часто встречающаяся сейчас проблема - choke, желтизна на графике, который должен быть зеленым
Симптомы - рост пинга при большом количестве игроков, либо на картах, где видно одновременно много объектов, задержка стрельбы, может быть видно передвижение других игроков и объектов рывками.
Причина: Сервер генерирует больше данных, чем может передать.
Решение: Нужно увеличивать скорость, выделяемую клиенту. Ставим rate побольше (например 300000) и смотрим, что произойдет. Если желтизна исчезла - можете поздравить себя с решением проблемы Если нет - пытаемся достучаться админу сервера. Если админом являйтесь вы, то тогда ставим в хлдсе sv_maxrate побольше (100000 например). Можно так же поднять и sv_minrate - это поможет игрокам с дефолтным конфигом (там вроде стоит rate 6000) избежать choke-ов и лагов.
5. Тут бы наблюдаем явную гребенку на нижнем графике - это означает что клинет получает данные через слишком большие интервалы времени. В игре может выражаться небольшим ростом пинга, небольшим подергиванием объектов, игроков.
Причины: низкий cl_updaterate или очень маленький sv_maxupdaterate на серверное стороне. Лечится увеличением значений этих переменных. Так же такое поведение может вызываться очень низким серверным ФПС (< 50). Решается разгрузкой процессора на сервере, либо поднятием значения sys_ticrate (если он имеет малое значение, т е < 100). Можно еще поставить плагины для увеличения серверного фпс, только при перегруженном ЦП они не спасут.
6. Здесь можно лицезреть фриз на серверной стороне - был очень большой перерыв между обработками кадров на сервере. На нетграфе выражается подскоком на нижнего графике десинхронизации, при этом с доставкой пакетов проблем не было (верхний график в норме).
Причин несколько:
1) обычно связана с высокой загрузкой диска на сервере, когда хлдс пытается что-либо прочитать - происходит задержка.
2) может происходить из-за блокирующих запросов в перегруженную субд. Решение - переходим на неблокирующие (threaded) запросы, правда тут без переписывания кода плагинов не обойтись
3) низкий приоритет, данный хлдсу. Если на сервере нашелся процесс с намного более высоким приоритетом, чем хлдс, при этом он загрузил весь (все) ЦП, то хлдс отправляется курить на это время.
Автор статьи: gudaus
Рейты - общее название для параметров, определяющих частоту и объём обмена информации сервера с клиентом. Существует ряд причин, по которым игра на сервере может быть некомфортной для клиента, то есть с лагами. Это:
- Ддос. Тут он нас ничего не зависит, с таким справляется хостинг/Датацентр.
- Неправильно настроенные рейты. А вот это можно поправить.
- Плохая связь у конкретного клиента с сервером. Виновен провайдер клиента, опять же мы помочь не можем ничем.
- Плохие маршруты у хостинга/VDS. Надо разговаривать с ТП. Если ничего не решается за неделю, то выход один - переезжать на другую локацию, так как подобные проблемы приводят к лагам у всех игроков и нежеланию играть на таком сервере. Зачем нам терять онлайн из-за подобных вещей?
- sv_maxrate и sv_minrate - максимальное / минимальное количество байт за одну секунду времени которые сервер посылает клиенту, включая потери пакетов (loss).
- sv_minupdaterate и sv_maxupdaterate - минимальная / максимальная частота отсылки обновлений от сервера к клиенту. Влияет на фпс. Если сервер отошлёт клиенту, к примеру, 40 обновлений за 1 секунду, у клиента фпс будет 40 либо ниже.
- loss - количество потерянных пакетов из последних 100. Пакеты могут теряться из-за перегрузки канала либо плохой связи между сервером и клиентом. Проблема в 90% случаев неустранимая.
- choke - количество пакетов, отправка которых была задержана сервером, чтобы не превысить лимит полосы, устанавливаемый sv_minrate, sv_maxrate. Также зависит от sv_minupdaterate и sv_maxupdaterate. Причина - сервер генерирует либо слишком много трафика. Это проблему можно решить настройками.
Настройка рейтов - дело для каждого сервера индивидуальное, зависящие от железа, канала, билда, нагруженности, так что искать некие "оптимальные" в интернете - занятие интересное, но, увы, малополезное. Лучше это сделать самому по следующим принципам:
- sv_maxrate 20 000 на билдах 5***. sv_maxrate 50 000-100 000 на билде 6***. На билдах 5*** выше, чем 20 000 устанавливать было нельзя. Вы можете прописать любое число в конфиге, хоть миллион, но реально максимум будет 20 000. На билдах 6*** появилась возможность повысить до 100 000, но если канал связи не очень хороший, то имеет смысл поискать оптимальное значение в диапазоне 50 000 - 100 000.
- sv_minrate 50 000 - 100 000 на билдах 5***. sv_minrate 25 000 на билдах 6***. Да, на билдах 5*** нельзя было выставить sv_maxrate больше, чем 20 000, но это обходилось условием sv_minrate. Никакой магии, дело в принципе отбора рейтов HLDS. Работает это так:
Код:
if rate>sv_maxrate then rate=sv_maxrate;
if rate<sv_maxrate then rate=rate;
if rate>sv_minrate then rate=rate;
if rate<sv_minrate then rate=sv_minrate;- sv_minupdaterate 20-30. 20 - значение по умолчанию, 30 - разумный минимум для человеческого глаза.
- sv_maxupdaterate 60 - 101 для билдов 5*** и sv_maxupdaterate 60 - 102 для билдов 6***
Заходим в server.cfg, сперва выставляем всё по максимуму.
Для билдов 5*** это
Код:
sv_maxrate 20000
sv_minrate 100000
sv_minupdaterate 30
sv_maxupdaterate 101
Код:
sv_maxrate 100000
sv_minrate 25000
sv_minupdaterate 30
sv_maxupdaterate 102- Если сервер фризит, то понизьте sv_minrate на билде 5*** / sv_maxrate на билде 6***. Понизьте sv_minupdaterate до 20.
- Если у клиента choke, то имеет смысл повышать sv_minrate. По сути на билде 5*** вы должны жёстко задать rate клиенту путём sv_minrate>sv_maxrate, а на билде 6*** можно поэкспериментировать с sv_maxrate 100 000 sv_minrate [20 000; 100 000]. Значения выше 100 000 ставить крайне не рекомендуется. Также можно понизить значение sv_maxupdaterate. Зачем слать обновления клиенту, если они всё равно не доходят? Но лучше всего будет, если вы сумеете убрать choke и фризы, не уменьшая sv_maxupdaterate.
- Если избавились от фризов и choke, то можно попробовать потихоньку снижать рейты, дабы лишний раз не нагружать канал. Понизьте sv_minupdaterate до 20, к примеру. Потихоньку снижайте sv_minrate.
Вопросы и ответы
Я видел, что на билдах 6*** ставят sv_minrate 100 000, sv_maxrate 25 000, как на старых. А в статье сказано ставить наоборот. Где правда?
Ответ: никакой путаницы нет. Вспомним правило расчёта рейтов
Оно одинаково для всех билдов.
В случае с sv_minrate 100 000, sv_maxrate 25 000 клиентский rate жёстко задаётся в 100 000. На старых билдах делали именно так, потому что не было возможности превысить ограничение в 20 000 иначе.
В случае с sv_minrate 20 000, sv_maxrate 100 000 клиентский rate колеблется между значениями 20 000 и 100 000. На стиме и клиентах нового билда это оптимально, на клиентах старого билда (с бустов) rate клиента станет скорее всего 25 000, так как именно такое значение чаще всего прописывают владельцы бустов. Его можно увеличивать, повышая sv_minrate.
Поясню на примерах
В случае с билдом 6***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000, sv_maxrate 100 000 => rate между 30 000 и 100 000 на стимах, 30 000 на бустах.
sv_minrate 10 000, ssv_maxrate 50 000 => rate между 10 000 и 50 000 на стимах, 25 000 на бустах.
Откуда 25 000? Это значение чаще всего выставляют владельцы бустов в клиенте.
В случае с билдом 5***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000,sv_maxrate 100 000 => rate 30 000
sv_minrate 10 000, sv_maxrate 50 000 => rate между 10 000 и 20 000, скорее всего 20 000.
Откуда 20 000? Владельцы бустов в клиенте обычно ставят 25 000, но сервер с билдом 5*** поддерживает только sv_maxrate <=20 000
Ответ: никакой путаницы нет. Вспомним правило расчёта рейтов
Код:
if rate>sv_maxrate then rate=sv_maxrate;
if rate<sv_maxrate then rate=rate;
if rate>sv_minrate then rate=rate;
if rate<sv_minrate then rate=sv_minrate;В случае с sv_minrate 100 000, sv_maxrate 25 000 клиентский rate жёстко задаётся в 100 000. На старых билдах делали именно так, потому что не было возможности превысить ограничение в 20 000 иначе.
В случае с sv_minrate 20 000, sv_maxrate 100 000 клиентский rate колеблется между значениями 20 000 и 100 000. На стиме и клиентах нового билда это оптимально, на клиентах старого билда (с бустов) rate клиента станет скорее всего 25 000, так как именно такое значение чаще всего прописывают владельцы бустов. Его можно увеличивать, повышая sv_minrate.
Поясню на примерах
В случае с билдом 6***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000, sv_maxrate 100 000 => rate между 30 000 и 100 000 на стимах, 30 000 на бустах.
sv_minrate 10 000, ssv_maxrate 50 000 => rate между 10 000 и 50 000 на стимах, 25 000 на бустах.
Откуда 25 000? Это значение чаще всего выставляют владельцы бустов в клиенте.
В случае с билдом 5***
sv_minrate 100 000, sv_maxrate 25 000 => rate 100 000
sv_minrate 70 000, sv_maxrate 40 000 => rate 70 000
sv_minrate 30 000,sv_maxrate 100 000 => rate 30 000
sv_minrate 10 000, sv_maxrate 50 000 => rate между 10 000 и 20 000, скорее всего 20 000.
Откуда 20 000? Владельцы бустов в клиенте обычно ставят 25 000, но сервер с билдом 5*** поддерживает только sv_maxrate <=20 000
Что такое фриз и как понять, есть ли он?
Ответ: Фриз - остановка игры. От английского Freeze. Представляет собой кратковременную остановку. Игровой мир замирает, после чего игра продолжается. Обычно бывают 2 ситуации - или небольших фризов много, каждый - доли секунды, или фризов мало, на каждый - по 1-2 секунды. На графике net_graph 1/2 выглядит как резкое подскакивание фиолетовой полоски вверх.
Ответ: Фриз - остановка игры. От английского Freeze. Представляет собой кратковременную остановку. Игровой мир замирает, после чего игра продолжается. Обычно бывают 2 ситуации - или небольших фризов много, каждый - доли секунды, или фризов мало, на каждый - по 1-2 секунды. На графике net_graph 1/2 выглядит как резкое подскакивание фиолетовой полоски вверх.
От Себя хотелось бы еще добавить вот такой мануал ... автор: berq!
Некий мануал по net_graph
Итак, чтобы избавиться от лагов, надо знать их причину. А причину нам поможет узнать очень хорошее встроенное в хл средство под названием 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 для клиента, то есть у клиента есть данные для отправки, но отправить он их не может, так как время отправки еще не подошло). В случае, если пакеты отправляются на сервер после отрисовки каждого кадра, графика вообще не видно.
Второй график - фиолтеовый в нижней части и красный в верхней - показывает уровень десинхронизации состояния клиента и сервера. Если присмотреться внимательно, то он представляет собой гребенку (типа вот так - //////). Степень десинхронизации зависит от того, когда был получен последний пакет от сервера. Следствия - при только что полученном пакете десинхронизация минимальна, а при большой задержке входящих пакетов - максимальна ( график в таком случае превращается в красную полосу в верхней части)
Для начала дадим описание того, что там вообще отображается:
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) и смотрим, что произойдет. Если желтизна исчезла - можете поздравить себя с решением проблемы
Если нет - пытаемся достучаться админу сервера. Если админом являйтесь вы, то тогда ставим в хлдсе sv_maxrate побольше (100000 например). Можно так же поднять и sv_minrate - это поможет игрокам с дефолтным конфигом (там вроде стоит rate 6000) избежать choke-ов и лагов.5. Тут бы наблюдаем явную гребенку на нижнем графике - это означает что клинет получает данные через слишком большие интервалы времени. В игре может выражаться небольшим ростом пинга, небольшим подергиванием объектов, игроков.
Причины: низкий cl_updaterate или очень маленький sv_maxupdaterate на серверное стороне. Лечится увеличением значений этих переменных. Так же такое поведение может вызываться очень низким серверным ФПС (< 50). Решается разгрузкой процессора на сервере, либо поднятием значения sys_ticrate (если он имеет малое значение, т е < 100). Можно еще поставить плагины для увеличения серверного фпс, только при перегруженном ЦП они не спасут.
6. Здесь можно лицезреть фриз на серверной стороне - был очень большой перерыв между обработками кадров на сервере. На нетграфе выражается подскоком на нижнего графике десинхронизации, при этом с доставкой пакетов проблем не было (верхний график в норме).
Причин несколько:
1) обычно связана с высокой загрузкой диска на сервере, когда хлдс пытается что-либо прочитать - происходит задержка.
2) может происходить из-за блокирующих запросов в перегруженную субд. Решение - переходим на неблокирующие (threaded) запросы, правда тут без переписывания кода плагинов не обойтись
3) низкий приоритет, данный хлдсу. Если на сервере нашелся процесс с намного более высоким приоритетом, чем хлдс, при этом он загрузил весь (все) ЦП, то хлдс отправляется курить на это время.
