t0x1c_r1v3r указал на наиболее грубые ошибки, ну а я хочу конкретизировать.
Optima писал(а):Ну что ж, начнём.
1.0 Серверная часть:
tickrate
Единица времени сервера - тик, чем больше этих тиков, тем плавней у клиента будет картинка(меньше лагов), тем лучше игроку будет играть. Это означает, чем больше у вас тиков с сервером, тем быстрее сервер будет реагировать на действия клиента. Тикрейт сервера зависит от канала и железа сервера.
Очень неточно сформулированное разъяснение. Это как раз
у сервера "картина" игрового мира от высокого тикрейта будет плавнее. Клиент - это отдельная песня, он как зеркало для сервера, при том обычно кривое :) .
Фраза "чем больше у вас тиков с сервером" вообще бредом попахивает.
Насчет зависимости от канала и железа. Допустим есть 100-тиковый сервер. Он будет 100-тиковым, и должен выдавать 100 тик, даже если канал отдачи позволяет отправить каждому клиенту лишь 80 пакетов, вместо 100. И страдать от этого сервер не будет, в отличии от клиентов, которые недополучат 20 пакетов каждую секунду, а это серьезные лаги.
Зависимость от железа, то-есть показателя FPS сервера более очевидна. Если пригрузить сервер до уровня 80FPS, 100 тиков он никак не успеет просчитать. И теперь лаги будут и на стороне сервера тоже.
Осталось добавить, что в Source есть 3 значения серверных тикрейтов: или 33, или 66, или 100.
Optima писал(а):2.0 Клиентская часть:
Определения
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 сервера проку особого, к сожалению, нет.
Optima писал(а):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
Optima писал(а):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
Optima писал(а):Тогда я вам скажу, мы нашли оптимальное значение rate для скорости 256 кб/с.
Надеюсь, будет учтено все выше мною изложенное.
Отлично особенности сетевого кода Source описаны тут:
http://www.jason35.com/Netcode.htm (на английском).
Optima писал(а):Примечание: максимальное значение updaterate и cmdrate устанавливаются сервером(tickrate)!
Осталось сказать, что update/cmdrate могут иметь значения 0-100. И максимальное определяется не всегда тикрейтом (помним о sv_maxupdaterate, sv_maxcmdrate). Однако ставить на клиенте меньше 33 считаю преступлением
Optima писал(а):In - число получаемых пакетов. В следующем столбике вы видите скорость приёма этих пакетов.
Первое число идет размер в байтах последнего полученного пакета, за ним правее входящий трафик в килобайтах/с, и только последнее крайнее правое число - число полученных пакетов за секунду.
Optima писал(а):Out - число передаваемых пакетов. В следующем столбике вы видите скорость отправки этих пакетов.
Первое число идет размер в байтах последнего отосланного пакета, за ним правее исходящий трафик в килобайтах/с, и только последнее крайнне правое число - число отправленных пакетов за секунду.
Optima писал(а):Ping - задержка между сервером и клиентом в милисекундах. Чем меньше задержка, тем быстрей у вас из дула будут вылетать пули. :)
Быстрее hit registration на сервере - да. Но не быстрота вылета пуль.
P.S.
Optima писал(а):Также в примере виден Source2007 и TF2, поскольку эта игра более популярна чем ксс и другие онлайн игры на этом source.
о_0
http://store.steampowered.com/stats/
Жмешь »View Steam players per game
Еще не разу не видел, что бы игроков TF2 было хотя бы в половину КССовцев. И дело тут не в том, что в стате берутся только игроки с лицензий.