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

Автор статьи: gudaus

Рейты - общее название для параметров, определяющих частоту и объём обмена информации сервера с клиентом. Существует ряд причин, по которым игра на сервере может быть некомфортной для клиента, то есть с лагами. Это:

1. Ддос. Тут он нас ничего не зависит, с таким справляется хостинг/Датацентр.
2. Неправильно настроенные рейты. А вот это можно поправить.
3. Плохая связь у конкретного клиента с сервером. Виновен провайдер клиента, опять же мы помочь не можем ничем.
4. Плохие маршруты у хостинга/VDS. Надо разговаривать с ТП. Если ничего не решается за неделю, то выход один - переезжать на другую локацию, так как подобные проблемы приводят к лагам у всех игроков и нежеланию играть на таком сервере. Зачем нам терять онлайн из-за подобных вещей?

Вначале пройдёмся по терминологии.

1. sv_maxrate и sv_minrate - максимальное / минимальное количество байт за одну секунду времени которые сервер посылает клиенту, включая потери пакетов (loss).
2. sv_minupdaterate и sv_maxupdaterate - минимальная / максимальная частота отсылки обновлений от сервера к клиенту. Влияет на фпс. Если сервер отошлёт клиенту, к примеру, 40 обновлений за 1 секунду, у клиента фпс будет 40 либо ниже.
3. loss - количество потерянных пакетов из последних 100. Пакеты могут теряться из-за перегрузки канала либо плохой связи между сервером и клиентом. Проблема в 90% случаев неустранимая.
4. 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. Работает это так:

Код:

1 2 3 4 5

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;

Под rate имеется в виду клиентский rate. То есть что происходит? В начале HLDS смотрит на maxrate. Если клиентский выше, то понижаем до серверного, если ниже - оставляем как есть. Затем HLDS смотрит на minrate. Если клиентский выше серверного, то оставляем всё как есть, а если клиентский ниже серверного, то приравниваем клиентский к серверному. Вот и получалось на билдах 5***, что клиентский rate всегда ниже, чем серверный(100 000), и принудительно выставлялось значение 100 000. На билдах 6*** максимальное значение sv_maxrate повысили до 100 000, и эта хитрость стала бессмысленной.

• sv_minupdaterate 20-30. 20 - значение по умолчанию, 30 - разумный минимум для человеческого глаза.
• sv_maxupdaterate 60 - 101 для билдов 5*** и sv_maxupdaterate 60 - 102 для билдов 6***

Теперь можно начать выставлять значения. 

Заходим в server.cfg, сперва выставляем всё по максимуму. 

Для билдов 5*** это

Код:

1 2 3 4

sv_maxrate 20000 sv_minrate 100000 sv_minupdaterate 30 sv_maxupdaterate 101

Для билдов 6*** это

Код:

1 2 3 4

sv_maxrate 100000 sv_minrate 25000 sv_minupdaterate 30 sv_maxupdaterate 102

Далее анализируем поведение сервера. Заходим в игру, включаем в консоли график нагрузки (net_graph 0/1/2/3), играем и параллельно смотрим на выданные в нём значения.

1. Если сервер фризит, то понизьте sv_minrate на билде 5*** / sv_maxrate на билде 6***. Понизьте sv_minupdaterate до 20.
2. Если у клиента 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.
3. Если избавились от фризов и choke, то можно попробовать потихоньку снижать рейты, дабы лишний раз не нагружать канал. Понизьте sv_minupdaterate до 20, к примеру. Потихоньку снижайте sv_minrate.

 

Спойлер

Что такое фриз и как понять, есть ли он?
Ответ: Фриз - остановка игры. От английского Freeze. Представляет собой кратковременную остановку. Игровой мир замирает, после чего игра продолжается. Обычно бывают 2 ситуации - или небольших фризов много, каждый - доли секунды, или фризов мало, на каждый - по 1-2 секунды. На графике net_graph 1/2 выглядит как резкое подскакивание фиолетовой полоски вверх. 

 Надеюсь вам пригодится! хотелось бы еще добавить вот такой мануал ... автор: berq!

 

Спойлер

Итак, чтобы избавиться от лагов, надо знать их причину. А причину нам поможет узнать очень хорошее встроенное в хл средство под названием 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) и смотрим, что произойдет. Если желтизна исчезла - можете поздравить себя с решением проблемы :) Если нет - пытаемся достучаться админу сервера. Если админом являйтесь вы, то тогда ставим в хлдсе sv_maxrate побольше (100000 например). Можно так же поднять и sv_minrate - это поможет игрокам с дефолтным конфигом (там вроде стоит rate 6000) избежать choke-ов и лагов.


5. Тут бы наблюдаем явную гребенку на нижнем графике - это означает что клинет получает данные через слишком большие интервалы времени. В игре может выражаться небольшим ростом пинга, небольшим подергиванием объектов, игроков. 
Причины: низкий cl_updaterate или очень маленький sv_maxupdaterate на серверное стороне. Лечится увеличением значений этих переменных. Так же такое поведение может вызываться очень низким серверным ФПС (< 50). Решается разгрузкой процессора на сервере, либо поднятием значения sys_ticrate (если он имеет малое значение, т е < 100). Можно еще поставить плагины для увеличения серверного фпс, только при перегруженном ЦП они не спасут.

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