| zOyBiRg |
Дата: Суббота, 15.11.2014, 16:54 | Сообщение # 1 |
|
| Интернет оптимизация Dedicated Server
Долго и много эксперементировал и мучался с настройками своего сервера, вроде как так !?!?! есть мощное железо, хороший пропускной канал, хороший отклик пинга, интэрнэт напрямую в "мир" но двигатель Unreal класть хотел на всё это. На стороне клиентов лаги, прыгающий пинг, вылеты. Перерыл много страниц великой паутины, много изучал и тыкал и вот более менее нащупал оптимальную конфигу сервера для дружбы его с интэрнэтом. Делюсь, пользуйтесь:
Руководство игрока по сетевому коду Unreal Tournament
1. Вступление
Этот материал - попытка разобраться в том, как UT ( двигатель Killing Floor ) работает онлайн, что такое пинг и лаг, как все работает и как получать информацию посредством статистики, заложенной в UT. Возможно, будет полезно всем - от продвинутых игроков до серьезных администраторов серверов. Если вам не все будет понятно в этом материале, не стоит беспокоится - на качество игры это не повлияет (как-то вы играли столько времени, не читая этого  )
Но если вы всегда хотите знать лагает ли ваш сервер из-за перегрузки процессора или почему только что выпущенные вами ракеты прямо в лицо противнику не нанесли ему вреда - этот материал даст вам ответы.
2. Основы интернета
Здесь описывается базовая информация: что такое "скорость" и качество соединения в интернет. Если вы уже знаете, что такое пинг/задержка и потеря пакетов можете пропустить это.
Обычно, скорость соединения определяется в килобайт/сек или килобит/сек. Эта скорость называется пропускной способностью канала. Второй компонент называется задержкой и определяется временем, необходимым для передачи данных по назначению. Считается обычно в милисекундах (1/1000 секунды, ms) и определяет пинг (величина пинга как правило равна задержке, умноженной на два, поскольку данные нужно сначала передать и потом получить ответ). Значение обоих факторов можно представить на примере: машина, груженая тысячей хард-дисков по 10 гигобайт каждый едет к примеру со скоростью 50км/ч, если длина ее пути равняется 100км то скорость передачи данных на расстояние таким образом составит 1 гигобайт в секунду! Нет желания поиграть через такое "соединение"? 
Игроки UT знают, что есть много разных вариантов пинга, в том числе в UT но в большинстве своем это не стандартный icmp пинг.
Если вы хотите выяснить причину плохой связи с сервером, неплохо для начала проверить маршрут передаваемой вами информаци до него. Узнайте адрес сервера (ip или url), откройте окошко доса и напишите в нем "tracert (ip/url)". Вы увидите весь путь, который проходят ваши данные с указанием пинга до каждого участка "hop".
tracert
Если вы увидите увеличенный пинг в некоторых местах (к примеру в начале 30, а потом 100 и выше) можете быть уверены: в ваших проблемах виноват не сервер и не ваш компьютер, а интернет. Здесь вы ничего не сможете сделать, разве что обратится с этими данными к своему провайдеру (или сменить его или выбрать другой игровой сервер - прим. пер.)
Существует много инструментов для выяснения маршрутов помимо виндового, мне например нравится plotter (Pingplotter), вы можете выбрать любой другой.
В интернет информация передается пакетами. Если по какой-либо причине (например испорченное оборудование в одной из точек по пути) часть пакетов может потерятся и не достичь назначения, это называется потеря пакетов. Чтобы выяснить где именно это происходит, используйте программы, указанные выше (например тот же plotter). Если потеря происходит в первой же точке, проблема скорее всего с в ваших настройках или оборудовании. Если это происходит в последней точке (сервер) скорее всего что-то не так - вы уже догадались - с сервером.
Примеры хороших соединений (данные приведены для Германии, в других странах значения могут быть иными. Взято с форума.):
Код ISDN...............- ~20 ms до первой точки, 30 ms до сервера
TDSL (no fastpath)- ~30-60 ms до первой точки, 40-80 ms до сервера
TDSL (fastpath)....- почти нет (~5 ms) лучше чем ISDN
QDSL...............- ~10-15 ms до первой точки, 25-35 до сервера
Если ваши значения сильно разнятся с этими, значит или провайдер плохой, неправильная настройка компьютера либо длинные маршруты до серверов.
3. Основы статистики и настроек UT
В UT существуют 2 вида пинга. Оба отличаются друг от друга. Причина проста - они высчитываются по-разному.
Пинг 1 показывает пинг сервера до вас, пинг 2 показывает пинг от вас до сервера. Если icmp пинг не показывает подобной разницы, то UT показывает, поскольку серверу и клиенту необходимо различное время для отправки данных.
Вторая важная вещь - потеря пакетов. Отображается дважды в столбцах IN и OUT - IN показывает то, чо вы получаете с сервера, OUT это трафик от вас к серверу.
Потеря пакетов может происходить как в каждом направлении по отдельности так и в обоих одновременно (что наиболее часто). В этом случае вы, как клиент, будете недополучать важную информацию (такую, как летящие в вас ракеты, перемещение вокруг вас игроков) и/или сервер не будет ее получать (не будет знать куда вы прицелились, ракеты будут выстреливать вам под ноги)
Все причины потери пакетов смотрите выше во второй части статьи.
Немного о том, что вы можете настроить для онлайн-игры как клиент в UT это только скорость соединения. Первое: забудьте о рекомендованных Unreal значениях. Второе: да, клиентский fps зависит от скорости соединения. Тем не менее это не играет большой роли, поскольку устанавливает некий максимум на ваши fps. Как результат вы будете иметь меньшее значение средних fps, но в важных ситуациях они не будет падать.
Принимая это во внимание, вы должны всегда устанавливать вашу скорость соединения согласно реальной пропускной способности вашей линии. Учитывая при этом трафик в обе стороны одинаков (полный дуплекс) или нет (half duplex и вариации). Для евро isdn 64k скорость должна быть 6500 (это не полный дуплекс, но может поддерживать в принципе 6.5 kb/sec в обоих направлениях одновременно). Для быстрых линий - DSL и аналогов нормальная скорость 20000 (вы по-любому никогда не получите больший одновременный трафик в обоих направлениях), но если у вас проблемы на некоторых серверах попробуйте уменьшить это значение - вполне может быть по пути от вас до сервера "бутылочное горлышко" на одном из участков маршрута пакетов. Как правило так и бывает при игре на больших расстояниях (из страны в страну или если сервер на другом континенте) .
Если указанная вами скорость слишком высока это даст вам на вид больше fps, но может принести проблемы если ваш компьютер действительно мощный, вы создадите больше трафика до сервера чем ваше соединение сможет вместить. Даже при определении сервером максимальных значений для клиентов (maxclientrate) не сможет исправить ситуацию, так как определяется сервером до вас, но не ваш трафик до сервера.
Так, вы все настроили, пинг хороший, нет потерь пакетов но все еще лагает? Это может быть по нескольким причинам. Если у вас лаги на всех серверах, в первую очередь проверьте свои настройки. Фаэрволы, вирусные сканнеры, ICQ и другие IM клиенты могут вмешиваться в онлайн-игру UT, поэтому стоит попробовать все это отключать на время игры и смотреть не стало ли лучше. Проверьте драйверы для устройства соединения (в особенности если у вас ISDN), но так же и для видеокарты и других устройств. Если вы подключаетесь к внешнему модему (DSL или кабель) через локальную сет, ваша сетевая карта возможно нуждается в новых/других драйверах либо присутствуют irq конфликты в распределении ресурсов компьютера.
Если ничего из вышеуказанного не помогло, самое время проверить сервер, что мы и сдлаем в следующем разделе.
4. Advanced stats ( ввести в игре на сервере, эту команду)
Stat net выдает больше информаци чем просто пинг и потеря пакетов. Посмотрим на рисунок:
Ping...............- если вы все не знаете что это, вернитесь ко 2 части.
Channels.........- число актеров на сервере, непосредственно в контакте с вами. Об этом в 6 части ниже.
Все нижеследующее показано в двух направлениях IN от сервера к вам, OUT от вас к серверу.
Unordered/sec...- число пакетов, полученных не в том порядке, в каком были отправлены. Если не равно всегда 0, что-то в вашем соединении конкретно через жопу.
packet loss........- процент потерянных пакетов. Должен быть всегда 0 . Если значение не равно нулю, проверьте свое подключение по разделу 2.
packets/sec.......- число полученных/отправленных пакетов в секунду.
bunches/sec.......- число обновлений актеров полученных/отправленных в секунду. Подробнее об этом в части 6.
bytes/sec...........- число байт полученных/отправленных в секунду.
netspeed............- догадайтесь сами.
Для игрока, кроме пинга и потери пакетов здесь может представлять интерес число байт в секунду. Всегда ограничивается скоростью подключения (netspeed). Для OUT никогда не должно превышать значения netspeed, для этого существует ограничение кадров. Если превышает со стороны IN вы будете терять часть получаемой информации. Если это происходит в исключительных случаях - не стоит беспокоится; если происходит регулярно вы будете недополучать необходимые данные. Причиной этому может быть беспричинное завышение параметра tickrates в настройках сервера.
Tickrate - это "fps" на которых работает сервер. Наиболее важный параметр, котрый серверный администратор может изменять. Здесь две стороны медали: повышенный tickrate означает большую загрузку процессора и больший трафик от сервера к клиенту, но в то же время дает игрокам лучший пинг.
По умолчанию tickrate (30 для интернет серверов) приводит к жуткому пингу - когда сервер работает на 30 тиках в секунду означает 1/30-ю часть секунды он будет думать прежде чем среагирует на пинг клиента - это означает 60 ms! Так же это влияет на игру - если ваш сервер работает на 30 тиках значит все команды игроков будут ждать 60 ms прежде чем как-то смогут повлиять на игру. И прицеливание становится просто невозможным - подумайте сами какая может быть меткость при 23 fps. Если повернете быстро мышь экран будет перемещаться рывками на такой низкой скорости - вот, собственно, что может сделать сервер с вашим прицеливанием (и с вашими затратами на хорошую связь) при работе на такой низкой частоте. Это так же приводит к видимому увеличению дамаджа у продолжительно стреляющего оружия (пулемёты) - поскольку больше чем одиночные выстрелы попадают в цель.
В последний годы скорость интернэта повсеместно увеличиваеться. Можно встретить сервера со 100 тиками, что прекрасно для игроков с толстыми каналами (и если позволяет мощность серверного процессора и достаточно широкий канал для прокачки трафика) но совсем не хорошо для ISDN-игроков, поскольку генерит больше трафика, чем может принять 64 kbit линия isdn и будет приводить к потере пакетов от незначительной информации о дырках от пуль на стенах до серьезной о передвижении противника.
Как игрок вы не можете изменить эту ситуацию. Тем не менее, вы можете выяснить с каким тикрэйтом работает сервер. Напишите в консоли inject userflag 1 (значение 0 отключит функцию).
Первый номер (максимальный) тикрэйт сервера. Вы не можете тем не менее увидеть (configured netservermax-)tickrate путем простой проверки входящих пакетов в секунду - у linux-сервера ведут себя по-другому. Смотрите разделы 5 и 6.
Другая возможность команды userflag 1 определить баг пинга (известный в Windows 2000 и некоторых устаревших linux-системах). Следующий номер показанный на картинке число подключенных клиентов и по причине этого бага, по вине которого клиент не может по-нормальному отконнектиться от сервера после смены карты, число это может быть больше, нежели реально подключено игроков (плюс спектаторы) до тех пор пока действует баг пинга.
Последняя важная информация (для игрока), которая может быть получена с помощью команды userflag 1 это просмотр загрузки процессора.
3-й и 4-й номера отображают время, потребовавшееся серверу для последнего тика. Поскольку время определяется с "начала тика" и его "окончания", оно может быть использовано как индикатор загрузки cpu. Сервер выполняет (или пытается выполнять) частоту тиков в секунду, каждый из которых требует милисекунды net+act. Если net + act << 1/tickrate * 1000 - сервер имеет достаточно мощности для работы с такой частотой. На быстрых серверах я обычно вижу значения 1/3 и даже меньше, даже если на одной машине запущено несколько (UT и не-UT) игровых серверов.
Поскольку userflag 1 требует большого трафика и даже превышает netspeed/maxclientrate ограничения используйте эту команду только для анализа сервера и не во время игры.
Причина того, почему пинг по F1 ниже чем пинг stat net довольно проста: большинство клиентов работают на больших fps, нежели сервер. Таким образом сервер получает от клиента ответ быстрее чем клиент от сервера - он просто ждет 1/fps секунд (плюс реальный icmp пинг само собой). По некоторым странным причинам клиент отнимает половину этого кадрового времени (1/fps) из собственного пинга - поэтому вы всегда будете видеть меньший пинг на своей собственной машине чем другие видят у вас.
Еще одна вещь относительно пакетов в секунду: если ваш fps падает меньше этого значения вас будет лагать; это называется "невидимая потеря пакетов" поскольку ощущается как потеря пакетов, но потерь пакетов в статистике нет. Я испытал на себе нечто подобное, но похоже что UT не может нормально обрабатывать два пакета ожидающих в одном фрэйме. Нет решения для этой проблемы - я просто разгоняю UT чтобы получить больше fps. Пробуйте разные советы по твикингу или купите быстрый комп
5. Настройка сервера
Этот раздел для серверных администраторов; я постараюсь рассмотреть основные настройки, которые можно менять на сервере. Знания админского пароля вполне достаточно для конфигурации всего этого. Используйте "admin set ipdrv.tcpnetdriver " после входа в качестве админа в самой игре. Для получения текущих значений используйте "get" вместо "set" (и не используйте ).
Как можете видеть, все необходимые параметры находятся в секции IpDrv.TcpNetDriver файла Killingfloor.ini (или как там он у вас называется). Выглядит так:
Код [IpDrv.TcpNetDriver]
AllowDownloads=True // позволяет клиентам закачивать недостающие карты, моды и тому подобное с сервера
ConnectionTimeout=15.0 // время, которое сервер ждет после того как не получает данных от клиента прежде чем дисконнектить его"
InitialConnectTimeout=150.0 // то же самое, только когда клиент пытается приконнектиться. Если у вашего сервера баг "creeping ping" (см выше) установите в 15 или меньше
AckTimeout=1.0 // ничего не значит в версии KF
KeepAliveTime=0.2 // время, после которого сервер продолжает посылать пакет.
MaxInternetClientRate=10000// максимальная пропускная способность, разрешенная сервером->клиенту; для каждого клиента, используется минимальная клиентская скорость и maxclientrate, не влияет на трафик клиент->сервер.
MaxClientRate=20000 // тоже но для LAN
SimLatency=0 // ничего больше не значит в текущих версиях
RelevantTimeout=5.0 // оставьте по умолчанию - см часть 6
SpawnPrioritySeconds=1.0 // оставьте по умолчанию
ServerTravelPause=4.0 // время, которое сервер ждет после конца карты прежде чем начать новую
NetServerMaxTickRate=20 // серверный "fps" для инет-серверов
LanServerMaxTickRate=35 // серверный "fps" для lan-пати
DownloadManagers=IpDrv.HTTPDownload // не менять
DownloadManagers=Engine.ChannelDownload // не менять
Большинство указанных выше значений не должны изменяться и не дадут никакой разницы при их изменении. Но особое внимание нужно уделить InitialConnectTimeout (уменьшите до 15 если у вас баг "creeping ping") и разумеется наиболее дискутируемый параметр NetServerMaxTickrate, называемый чаще как тикрэйт (tickrate).
При определении какой тикрэйт использовать на вашем сервере, принимаются во внимание следующие нюансы:
- Серверная ОС: поскольку поведение Windows-серверов и Linux-серверов различны. Об этом чуть позже.
- Клиентские подключения: для ffa серверов (для всех) вы можете оставить (а можете и нет) сервер играбельным для модемщиков с крайне ограниченным трафиком; на серверах с большим онлайном ваши клиенты как правило имеют ISDN и выше соединения. Так же принимается во внимание играются ли международные игры на сервере - длинные международные маршруты могут иметь плохую пропускную способность даже для клиентов с хорошим локальным каналом.
- Максимальное число игроков и тип игры/мод: по идее, чем больше игроков на сервере тем больший трафик требуется каждому клиенту (больше видимых игроков - больше нужно отослать информации). Тип игры/мод не менее важен, поскольку один мод например производит больше спама и видимых игроков в момент времени, чем например другой, а полные переделки, генерят совершенно другой трафик, в больших количествах чем стандартный KF.
Итак: что отличает Linux сервер от Windows сервера? Известно многим: число отсылаемых ежесекундно пакетов не постоянно по отношению к netservermaxtickrate. По замыслу авторов игры, UT должен отсылать пакет в каждый тик (см часть 6), но даже при загрузке процессора менее 50%, Linux сервер старается отсылать меньше, не считаясь с определенным для этого числом пакетов. Это влияет и на пинг по F6 - если даже клиент получает всего 10 пакетов в секунду, ему придется ждать 100 ms пока на его пинг придет ответ!
Одна (возможно единственная) причина этому в кроется Linux UT threading. Threading это концепция, позволяющая мультизадачность: программы говорят операционной системе что они закончили со своим текущим заданием и так же получают процессорное время снова для работы. Похоже команды, делающие это в Linux UT, написаны не совсем коректно и сервер "спит" (между тиками) дольше, чем следует. Это означает, что сервер всегда будет работать с меньшей частотой тиков, чем указано в NetServerMaxTickRate. Частота, при которой это происходит меняется от времени и под воздействием других неизвестных факторов.
На сегодня это не лечится. В большинстве случаев похоже сервера пытаются отсылать минимальное число пакетов, ниже нормы, когда происходит "экшн" в игре, но это не правило. И как вывод Linux не желателен для серверов UT. Но это лично моё мнение.
С учетом вышесказанного, довольно сложно установить "прекрасный" тикрэйт для сервера. Прежде, чем я дам рекомендации, необходимо сообщить о том, как тикрэйт влияет на трафик. Конечно более высокий тикрэйт производит больший трафик, но рост его не линеен (2х тикрэйт совсем не означает 2х трафик). Причина проста: хоть некоторые вещи (такие как прицеливание игрока) реально улучшаются при увеличении тикрэйта и готовы отсылаться каждый тик, то другие вещи нет (игроки не начинают выстреливать в два раза быстрее, менять чаще направление движения). И когда нечего обновлять (новые направления перемещений, ...) никакого трафика для этого и нет. В результате, увеличение тикрейта на значение Х создаст увеличение трафика меньше чем в Х раз.
Принимая во внимание все это, некоторые рекомендации по установке тикрейта для различных ситуаций я дам. Информация касается Windows серверов; поскольку Linux сервера никогда не работают быстрее чем должны, значения могут использоваться и для Linux серверов. Значения подразумевают пропускную способность 5000 байт/секунду при полном дуплексе подключенных игроков если не указано иначе.
Далее приведены настройки исходя из классики или не большого от него отступления и хорошего интернет соединения, что в данное время проблемой быть не должно:
Сервер с 6 игроками: Тут все просто. С 6 игроками, создающими "действие" не бывает особых проблем с пропускной способностью; вполне хорошо будете себя чувствовать при тикрэйте 30.
Сервер на 12 игроков: Значения тикрэйта в районе 40 будут приемлемы. Если только игроки приконнектятся на скорости 6500 байт/сек но тикрэйт 50 будет лучшим вариантом.
Сервер на 20: Тикрэйт 50-55 будет в самый раз.
(Опять таки эти цифры не фактический путь к действию, всё зависет от того с чем вы работаете, да и эксперементы ни кто не запрещал)
Для международных игр вы должны уточнить действительно ли пропускная способность равна 5кб/сек между сервером и клиентом. Если клиенты начнут терять пакеты или будет расти пинг, что не происходит при малом тикрейте, стало быть где-то бутылочное горлышко.
Возможно вас поражает, почему Unreal рекомендовали намного ниже значения - этому есть две простые причины: они ориентировались на среднего покупателя, имеющего 56к ( на момент выхода движка в начале двухтысячных ) модем (а аналоговые модемы близко не стояли к полному дуплексу) и установили скорость соединения 2800 - и тикрейт сервера на 6 игроков. Соответсвенно нет причин сегодня использовать эти значения, особенно для серьезных игр. Вторая причина в том, что Unreal никогда не заботились о спортивности своей игры (UT) (модем 56к и мясо на 16 человек - ура бля !!! fun !!)
6. Advanced netcode
Эта часть повящена целиком деталям того, как сетевой код UT реально работает. Для понимания всего написанного знание основ объектно-ориентированного программирования рекомендуется, но не обязательно.
Итак, как же работает UT онлайн? Чтобы понять это, для начала необходимо понимать основы проблем всех онлайн игр в интернет. Эта проблема - задержка, с которой отсылаются данные поэтому абсолютно невозможно полностью синхронизировать всех игроков. Это означает, что игроки никогда не видят одно и то же, всегда есть задержка прежде чем игрок А увидит что делает игрок Б и куда прёт моб В.
Далее идёт описание на примере UnrealGame DeathMatch ( игроки друг против друга )
Как большинство игр сегодня, UT использует модель сетевого кода, где главным является сервер. Это означает, что сервер определяет что "на самом деле" происходит; он руководит всей игрой. Если сервер видит, что игрок А стреляет в игрока Б, игрок Б получает дэмедж - вне зависимости от того, видит ли Б что в него стреляет А или видит ли А что попадает в Б. Это означает так же что сервер решает где на самом деле находятся игроки.
Клиенты пытаются симулировать "реальный мир" сервера настолько насколько это возможно. Меткость при этом полностью зависит от пинга. Чтобы сделать эту симуляцию как можно ближе к действительности, существует два пути в сегодняшних играх. Первый состоит в том, чтобы дать возможность клиенту попытаться предсказывать состояние "реальной игры" исходя из имеющейся информации (это то, чем занимается UT), другой путь разрешить серверу "возвращать назад" ситуацию к тому моменту, когда было выполнено действие (так работает HalfLife и zeroping, UT-мод пытающийся делать в UT что-то подобное). Вторая модель указана здесь только для информации и не имеет отношения к UT.
Обе эти модели имеют за и против. В первой модели клиент всегда имеет информацию не соответсвующую действительности, другие игроки уже переместились в новых направлениях. Клиенты других игр пытаются распределить движение других игроков в соответсвии с пингом (QW одна из таких), UT этого не делает. Тем не менее, поскольку частота кадров клиента обычно выше чем число обновлений, получаемых с сервера, UT экстраполирует движение таким же образом, указанным выше, пока не получит новую информацию о перемещении клиента. Это причина "скользящих" игроков при лагах - UT экстраполирует их "старые" движения пока не получит информации о "новом" местоположении или направлении.
Во второй модели игроки которых подстрелили на чьем-то клиенте, продолжают думать что они на сервере в "реальном мире", но через некоторое время игроку сообщат что он был подстрелен (или даже убит) некоторое время назад. Никакие его выстрелы после того момента уже не считаются. Самый цирк происходит, когда игрок уже изчез из поля зрения другого и вообще в другом месте вдруг узнает что был убит.
Теперь когда мы знаем как все устроено можно посмотреть как это реализуется. Для полной симуляции всего происходящего сервер должен слать клиенту всю информацию о происходящем, что потребует слишком большого трафика. Для уменьшения нагрузки на соединение используется несколько вещей; некоторые из них (те, что влияют на игру) будут рассмотрены здесь.
Для понимания того, как эти метод работают мы должны взглянуть как это устроено в UT. Для всего, что присутствует в игре, существуют теплаты, называемые "класс". Каждый объект (те объекты, что имеют какое-либо отношение к игре, называются "актеры" в UT) имеет свойства. Например есть класс "ракеты" и каждый раз когда ракета создается (стреляет кто-то) получает свойства, основанные на классе.
UT использует различные свойства для актеров для определения как они отсылаются клиенту (либо в случае движения игрока от клиента серверу и от сервера другим клиентам)
Теперь о методах уменьшения трафика: если клинет не может видеть или слышать актера (будь то другие игроки, ракеты, гранаты или что-либо еще) нет причин сообщать коиенту что они делают. UT реально проверяет это (называется проверкой на отношение) и не воспроизводит актеров "вне поля зрения/слуха" клиента. Переменная "relevanttimeout" в [IpDrv.TcpNetDriver] на сервере определяет как долго актер может находиться в таком состоянии прежде чем будет иметь какое-то отношение к клиенту. Результат такой проверки можно видеть при воспроизведении клиентских демок от третьего лица (в таком режиме можно больше увидеть) - игроки, которые не видны были игроку, записавшему дему, невидимы, вы можете видеть как они реально пропадают как только игрок их не видит. Разумеется, как только они становятся видны (снова или впервые) сервер передает информацию о них клиенту.
Следующий важный метод заключается в симулировании поведения актеров где это только возможно. В перую очередь это распространяется на все метательные снаряды (типа ракет). Когда такое тело выстреливается, сервер сообщает клиенту в каком месте это рождается (создается) и в каком направлении летит. С этого момента клиент симулирует полет объекта без получения какой-либо дополнительной информации - клиент знает скорость, и, поскольку изменения направления произойти не может, серверу нет необходимости передавать клиенту обновленную информацию о местоположении объекта. Эта симуляция часто служит причиной "фантомных ракет", когда клиент видит как его ракеты попадают в другого игрока но тот не умирает. Причина проста: поскольку ракеты симулируются клиентом, клиент так же "решает" что их пора взрывать (визуально - дэмедж разумеется решается сервером). Поэтому если клиент видит что ракеты попали в игрока, они взорвались - но клиентский мир не существует, особенно для других игроков которые могли уже давно переместиться в "реальном мире" на сервере. Вы можете быть уверены в том, что нанесли дэмедж только в том случае, если увидите кровь на игроке или что его мясо воляется вокруг поскольку и кровь и моментальное изменение состояния игрока определяется только сервером.
Другой параметр, используемый для уменьшения трафика - "netupdatefrequency (возможно только в самом UT, но рассмотрю его здесь для полноты картины)", определяемый для каждого класса. Поскольку одни актеры (как движения игроков) требуют обновлений, а другие нет. На игру не оказывают никакого негативного влияния такие вещи как счет, поскольку не передаются 50 раз в секунду. Netupdatefrequency определяет как должны передаваться актеры клиенту (максимальное число). Netupdatefrequency можно заметить по задержкам оповещения игрока о его арморе при попадании в него - армор обновляется только 10 раз в секунду, таким образом до 100 ms может быть задержка прежде чем игрок будет информирован что его броника уже нет. Максимальное значение netupdatefrequency может быть 100, это так же очевидно как и тикрэйты > 100 неиспользуемы - ничего не может обновляться для клиента чаще чем 100 раз в секунду в любом случае.
Зная всю эту информацию, значения "channels" и "bunches" из stat net проще понять: channels это число актеров, непосредственно относящихся к вам; bunches отображает число обновлений актеров, которые были получены за последнюю секунду. Зная эти числа легко понять важность "нет изменений переменных - нет обновлений".
Другая вещь, которую стоит знать, состоит в том, что UT серверы всегда шлют клиентам пакет в конце тика даже если актеры этого не требуют. Это означает, что в большинстве случаев UT будет слать один пакет в каждый тик даже если нечего слать. Единственная причина, по которой число пакетов в секунду может быть меньше установленного тикрэйта в процессе реальной игры (не netservermaxtickrate - смотрите объяснение проблемы linux серверов в части 5) только в ограниченной пропускной способности клиентского соединения, не способной принять слишком большое число пакетов.
p.s.
Данная тема была написана на скорую руку. Возможно, что то упустил или есть ошибка, то потом отредактирую с пометкой "отредактировано"
Кстати немного с форумов CS:
Повышение FPS
К сожалению, оба типа серверов не достигнут этих значений FPS без одного небольшого улучшения. Чтобы получить достаточное обслуживание ОС, должен быть запущен таймер высокого разрешения. По умолчанию в системе запущен таймер низкого разрешения, который не даст показателю FPS подняться выше 100.
Запуск Media Player (вам не нужно проигрывать файл, просто откройте плеер) заставит ОС активировать таймер высокого разрешения, что позволит вашему серверу рассчитывать до 1000 FPS. В неактивном режиме Media Player требует только 5 МБ ОЗУ, так что это сравнительно низкая издержка для такого улучшения. Вы также можете запустить Macromedia SWF файл в обозревателе Internet Explore для наступления этого эффекта.
Процессоры Intel vs. AMD
Если вы вы установите переменную sys_ticrate (HLDS) или fps_max (SRCDS) на 1000, большинство процессоров от Intel, работающих на материнской плате с чипсетом Intel, выдадут 1000 FPS (плюс/минус несколько FPS). Если же у вас установлен процессор AMD или Intel, но он работает на материнской плате с чипсетом не от Intel, вы получите только 500 FPS.
Зачем более высокие FPS?
Основная причина устанавливать более высокие значения FPS — меньшее время расчета кадра. При 1000 FPS сервер рассчитывает кадр за 1 мс (миллисекунду). Это значит, что в худшем случае добавка в пингу игрока составляет всего 1 мс, следовательно, игрок получает более точные сведения более часто.
При 300 PFS эта добавка составляет 3 мс, что приемлемо, но вот при 100 FPS добавка составляет уже 10 мс, что является значительной частью пинга 100 (10%). Это значит, что игрок с таким пингом на самом деле будет иметь пинг 110. Многие системы AMD будут выдавать только 60 FPS, следовательно, добавка в пингу будет составлять 17 мс.
Это все еще не очень много, но все же может повлиять на ощущения от игры.
Без ускорения FPS ваш процессор будет нагружен значительно меньше, но это может сказаться на точности игры.
Источник: killingfloor.ru
Индивидуальность - это не просто набор уникальных скинов, оружия или мутаторов. Это своя атмосфера, стиль, который можно создать только в результате напряженной умственной деятельности © Freddy
|
| |
|
|
