Не претендую на 100% точность написанного, если кто сможет что-то внятное добавить поправлю.
Может кому нибудь, это поможет. План:
1. Tickrate на сервере.
2. Клиентские настройки рэйтов.
3. Как их настраивать.
4. AceRate - нужно или нет, добавленно.
1. Tickrate на сервере.
Сервер симулирует игровой мир в дискретные промежутки времени, названные "тик" (tick). По умолчанию используется 66 тиков в секунду, однако моды могут использовать свою собственную частоту тиков. Например, в Counter-Strike: Source используется частота 33 тика в секунду, чтобы снизить нагрузку на процессор. Во время каждого тика сервер обрабатывает пользовательские команды, симулирует физику, проверяет правила игры и обновляет состояние объектов игрового мира. После завершения симуляции тика, сервер определяет, каким клиентам требуется обновление и делает снимок состояния мира, если это необходимо. Более высокая частота тиков увеличивает точность симуляции, но требует больших ресурсов процессора и пропускной способности, как на сервере, так и на клиенте.
Возможные значения переменной -tickrate на серверах 33, 66 и 100. Чем Выше значение этой величины, тем более точные игровые данные сервер может отправлять клиенту, но и тем выше требования к каналу сервера, и косвенно к клиентам находящимся в игре. Не рекомендуется tickrate на сервере ставить другие, чем 33, 66 или 100, возможны глюки.
Наиболее правдоподобные настройки на сервере:
sv_mincmdrate 66
sv_maxcmdrate 100
sv_minupdaterate 66
sv_maxupdaterate 100
sv_minrate 20000
sv_maxrate 25000
2. Клиентские настройки рэйтов.
rate 20000 до 30000
cl_updaterate 66 или 100
cl_cmdrate 66 или 100
Теперь, как это привязывается к Tickrate на сервере:
Запускаем из консоли net_graph 3
1. Сервер – Rebel – Tickrate на сервере 66
Клиентские команды:
cl_updaterate 66
cl_cmdrate 66
Как видим значения 67,0 и 67,1 соответствуют ограничениям на сервере.
2. Сервер – Rebel – Tickrate на сервере 66
Клиентские команды:
cl_updaterate 100
cl_cmdrate 100
В данном случае значения 67,0 и 66,5 явно ограничиваются тикрэйтом сервера.
3. Сервер – Rebel – Tickrate на сервере 66
Клиентские команды:
cl_updaterate 33
cl_cmdrate 33
В этом случае значения 33,7 и 34,1 показывают, что настройки клиента, будучи меньше, чем тикрэйт сервера, оказывают влияние, на обмен данными клиент-сервер.
4. Дополнительно Сервер – EXO – Tickrate на сервере 100
Клиентские команды:
cl_updaterate 66
cl_cmdrate 66
Подтверждение общего рассуждения, тикрэйт на сервере 100 – у клиента 66, ограничивается поток данных, кстати, косвенно влияет на Loss и Chok – меньше потерянных пакетов.
5. Дополнительно Сервер – EXO – Tickrate на сервере 100
Клиентские команды:
cl_updaterate 100
cl_cmdrate 100
А здесь соответственно видим, что при клиентских значениях, 100 на 100, сервер позволяет использовать обмен данными на тикрэйт 100.
Выводы, которые хочется сделать.
1. При Tickrate на сервере 66, без разницы, будет у клиента значения 66 или 100.
2. Если, у клиента значения меньше, чем 66, то он будет создавать нагрузку на сервере, по причине обновления данных сервером, и отсылания их клиентам не равномерно. Также, вместо того, чтобы отправлять данные единым блоком, серверу придется их, резать на 2, если у клиента настройки 33, как все это реализуется в сетевом движке не знаю, но точно, что обмен данными клиент-сервер-клиент будет не равномерен, что должно приводить к увеличению пакетов попавших в очередь, и сброшенных за ненадобностью, а последствия – сервер сам достроит игровую ситуацию, что для нас будет выражаться, в теме, да как же так – вся очередь в упор, а не попал не разу . Еще он будет дергаться, короткими рывками. особенно это заметно, если в спектре за ним смотреть.
3. Rate 20000 – это объем максимума в байтах, которые сервер, может за раз бросить клиенту, если клиент уменьшает это значение, то соответственно, будет брошено в несколько приемов. Туда же, вывод номер 2. Если посчитать килобайты, то максимальный объем пакета на 20000 будет 19,5 килобайт, этого достаточно на 20 слотов при тикрэйте 66, во всяком случае, у меня не разу больше не поднималось. Но при 100, в мясе уже может не хватить. Надо мерить. Поэтому не меньше 20000, а больше кажись без разницы, все равно данных то сервак в таких количествах не наберет, чтобы это перешло в разряд проблемы.
4. И еще касаемо ассиметричных значений типа 66 на 100, практически та же чушь. При стрельбе из-за разницы в пересылке данных, будет сервером достраиваться самостоятельно игровая ситуация, что не есть гуд.