tickrate
Это у сервера "картина" игрового мира от высокого тикрейта будет плавнее. Клиент - это отдельная песня, он как зеркало для сервера, при том обычно кривое .
Допустим есть 100-тиковый сервер. Он будет 100-тиковым, и должен выдавать 100 тик, даже если канал отдачи позволяет отправить каждому клиенту лишь 80 пакетов, вместо 100. И страдать от этого сервер не будет, в отличии от клиентов, которые недополучат 20 пакетов каждую секунду, а это серьезные лаги.
Зависимость от железа, то-есть показателя FPS сервера более очевидна. Если пригрузить сервер до уровня 80FPS, 100 тиков он никак не успеет просчитать. И теперь лаги будут и на стороне сервера тоже.
Осталось добавить, что в Source есть 3 значения серверных тикрейтов: или 33, или 66, или 100.
rate
Это переменная клиента, указывающая серверу максимальное количество байт, которое клиент готов принять от сервера за секунду.
Часто считают, что она должна отражать ширину входящего канала клиента, но для движка Source это не совсем так, верней, совсем не так.
Именно заниженное значение переменной есть частой причиной появления choke, т.е. пакетов, которые не доходят до клиента из-за узкого канала либо лимитированного rate'ом объема трафика за секунду.
Допустим, у меня канал на скачку 256kbit/s. Сервер за одну секунду хочет отдать моему клиенту 16000 байт. Но на клиенте стоит rate 10000. И сервер пошлет лишь 10000, ведь мой клиент сказал ему, что готов принять лишь столько. А остальные 6000 сервер просто обрежет и выбросит. В результате мой клиент недополучит ХХнадцать идущих подряд пакетов, что и отразиться на датчике choke.
В идеале, на движке Source клиент может установить себе как можно большее значение rate, даже в случае, если его входящий канал сможет пропустить в несколько раз меньше байт. Например, при rate 100000 датчик choke практически всегда будет показывать 0.
Увы, очень мало серверов, у которых достаточно широкий канал отдачи для всех клиентов и переменной sv_maxrate 100000. В основном из-за незнания админами сетевого протокола Source'а.
Потому, ставить rate выше, чем sv_maxrate сервера проку особого, к сожалению, нет
cl_updaterate
Это количество пакетов, которое клиент хочет получить от сервера.
Приведу пример. На клиенте стоит cl_updaterate 66, то есть клиент ожидает получать от сервера не более 66 пакетов в секунду. Возьмем два сервера с sv_maxupdaterate 100 (то есть позволят моему клиенту требовать 66 пакетов и даже больше), один на тикрейте 33, другой на 100. 33-тиковый сервер отдавать мне будет лишь 33 пакета, ведь он больше в секунду не просчитывает. 100-тиковый же отдавать будет лишь 66, ведь клиент большего числа не ожидает. А теперь представим, что у меня канал больше 70-75 пакетов не пропустит, а я поставил cl_updaterate 100. 100-тиковый сервер будет спокойно пытаться отдавать мне все 100 пакетов, и это не его (сервера) забота, что ко мне все 100 не дойдут.
Выходит, не смотря на отсутствие фиксированного размера пакета, в Source зависимость от ширины клиентского входящего канала должна быть видна в первую очередь по значению переменной cl_updaterate, а не rate, как думают многие. rate пускай будет чем повыше и сколько сервер позволяет (sv_maxrate), это сократит choke к минимуму. А вот завышенное значение cl_updaterate может привести к тому, что пакеты "не влезут" во входящий клиентский канал.
Значения updaterate, в зависимости от размера входящего канала, для игры на Source-сервере с 20 играющими обычно вполне достаточно:
до 128 kbit/s »» cl_updaterate 33
на 128-256 kbit/s »» cl_updaterate 66
на 512 kbit/s и выше »» cl_updaterate 100
cl_cmdrate
это количество пакетов, которое клиент хочет послать серверу.
Именно из-за заниженного значения этой переменной можно видеть на сервере игрока с минимальным пингом, но со страшными дерганиями и задержками анимации и действий. Попасть в такого игрока становиться трудно, ведь инфа о клиенте при низком cmdrate приходит редко, и серверу трудно угадать где ж эта св*лочь на самом деле находиться. В Source 2007, если я правильно понял, новый сетевой код позволяет серверу более удачно регистрировать попадания в таких лагеров.
Как и в случае с updaterate, cmdrate нужно брать в зависимости от ширины канала клиента на отдачу. Можно также учесть, что фактический cmdrate не будет выше за FPS в игре (точно так же как updaterate и tickrate выше FPS сервера).
Значения cmdrate, в зависимости от размера исходящего канала, для игры на Source-сервере несколько менее требовательны, ведь там информация только об одном игроке (клиенте):
до 32 kbit/s »» cl_updaterate 33
на 64-128 kbit/s »» cl_updaterate 66
на 256 kbit/s и выше »» cl_updaterate 100