Какой то боян

Вообщем ставлю цент, 10 человек - нагрузка на проц 30-40% - FPS приседает до 500
Ставлю вин , 10 человек - нагрузка на проц 10-15% - FPS стабильно 900-800

Кривые руки у меня , или как это называть еще?




Примерно 8 чел

Писал corax"y , ответа не получил. Из-за проблем пришлось убежать на вин

~310 тел играют (10 серверов по 32 слота) FPS ~550-600
CentOS 6

6 ядер, мм.. Вкусно
Хрен с нагрузкой, фпс важнее. К сожалению не могу получить стабильный фпс на центе

ты уже достал не там темы создавать

1 раз, тем более тут говориться еще о винде.
Кто подскажет что?

не ставь цент. используй венду. уходи.
я дал тебе 3 совета :3

зачем, надо было дать баян

1) Это были те же люди на той же мапе?
2) Винда коряво считает нарузку на проц от процессов, которые часто уходят в слип
3) В 2000-х годах сишний компилятор у микрософта оптимизировал лучше чем gcc => на винде движок лучше оптимизирван => нагрузка меньше

Ставь винду

верно, тогда почти все игрушки выходили под 98 виндоус )

помню играл

win 98 / 64 video 512 ram celeron 400 / duron 1 gz :)
дырявая винда, админа обходил на лишнее время в клубе

Если взять теорию вероятности, что у большинства игроков прописаны рейты 101 - то нагрузка должна быть больше.
При этом при входе на сервер прописываем рейты например 60 - результат оказывается странный. Т.к. нагрузка либо не меняется либо становится больше.

Посему - я не понимаю зависимость нагрузки от рейтов.

С другой стороны, мне известна другая зависимость - кол-во получаемых пакетов на получение информации о сервере и нагрузка. Прямо пропорциональна соответственно.

Как утверждение про апдрейт 101 связано с теорией вероятности?
А то я не вижу промежуточных рассуждений о существующих сборках кс, дефолтных рейтах в них и шансом того, что игрок будет менять конфиг. Просто вот так взяли и сказали, что у большинства апдрейт 101 и приплели упоминание о теории вероятности :)
Ну ок, большинство - это сколько? 99%? 90%? 50% + 1?
А что насчет rate? он не влияет ни на что? :)



Рейты надо не на входе прописывать, а менять прямо в игре у всех сразу. Тогда ступеньку на графике загрузки цп будет отчетливо видно.
Как-то так
0) sv_minrate 100000 чтобы не было чоке
1) sv_minupdaterate 20 + sv_maxupdaterate 20 + через амхх поменять ченить в setinfo у всех клиентов, чтобы сервер пересчитал рейты
2) sv_minupdaterate 101 + sv_maxupdaterate 101 + через амхх поменять setinfo всех клиентов
3) всё это время рисовать график нагрузки на проц


Тут всё просто - чаще посылаются апдейты => больше нагрузка, т.к. эти апдейты надо еще сформировать.

Зависимость от клиентского cmdrate тоже есть, всё верно.

извращенец. какое нафиг чоке, чоке это когда проц в планку нагружен или канала 1 мбит на 30 игроков.
25к более чем хватает, чтобы чоков не было. Клиент один фиг 20к воспринимает. нет смысла выжирать провайдерский трафик за зря :)

Бугугашеньки. То есть сначала ты говоришь, что чоке возникают из-за перегрузки проца или канала, а потом говоришь что rate 25к хватает чтобы чоки не возникали. Где логика? Почему 25к, а не 1к? ведь при 1к перегрузки канала и проца точно не будет :D

Ладно, разберем по порядку:

Когда проц в планку загружен, начинаются дикие просадки фпс, а не чоке.


Когда канал перегружен, начинаются потери пакетов, то есть loss, а не чоке.

Матчасть у вас на троечку с минусом :)

А чоке начинаются когда хлдс не может упихнуть трафик клиента в полосу, ограниченную rate, или, если быть точнее, когда в момент формирования апдейта _не_ выполняется условие:
[время_после_отправки_предыдущего_апдейта, сек] < [размер_предыдущего_апдейта, байт] / [клиентский_рейт, байт/сек]

Проанализировав эту нехитрую формулу можно увидеть, что увеличив клиентский_рейт можно сильно снизить вероятность появления чоке.


Моя практика показывает, что на мясосерверах не хватает


Слышали звон, да не знаем где он. Клиент со значением квара rate ничего не делает. Только передает его на сервер. А вот сервер уже использует его (см формулу выше) И да, сервер воспринимает значения больше 20к, но только если ограничнивать их снизу sv_minrate. В общем, при sv_minrate >20k, у всех игроков на сервере будет рейт = sv_minrate.


Ты не поверишь, но если у тебя на sv_minrate 25к нету чоке, и ты поставишь sv_minrate 1kk, то количетсво генерируемого трафика не поменяется вообще :)

berq, сваял бы статейку красивую =) заодно там всякие MAX_BACKUP и про всякие подобные штуки =) как новогодний подарок всем :D

про чок, если в канал (rate канал) не влезает это было уже.

Чок, это типа если есть что отправлять, но лимит исчерпан. А loss это реальный loss.
Поправьте если ошибаюсь =)

И да, с наступающим! :)

berq,
пурр спорить не буду.
но если проц забит под планку и фпс у тебя просаживается до 30 у тебя гарантированно будет чоке. не лоссы а именно чоке и неистовые латенси. сам выше объяснил почему.

На самом деле по рейтам вообще мне сложно что то говорить, никогда дела не имел... ну вплане нет проблем - нет дел)

но вот про чоке
чоке == та неловкая ситуация, когда твой комп не может принять те тысячи данных, что сервер посылает ему.

так что я вообще не вижу смысла в серверном рейте 100к

да, 25к и 1кк будет одно и тоже, опять же сам объяснил выше :3


в общем чоке от низкого фпс и неебических рейтов. алсо за 5 лет ни разу не сталкивался с глобальной проблемой с чоками - только у отдельных личностей и за опятьже кривых рейтов.
причем и интернеты разные были и 512к было
и 9к минрейт...никогда проблем не было. Я помню даже когда последний раз серваки лагали :) было это во времена 4х мбит + 4200+ амд и 4 сервера игровых на нем + клиент.

/fast add
и уж если будет чоке - то скорее всего из за неверных клиентских тикрейтов: апдрейтрейт и цмдрейт.
либо из за сервака, шутка ли, 32к обновлений в секунду при 1000 фпс на 32х игроках))

berq,
Я честно не сомневаюсь в твоих знаеиях, но минрейт 100к это не нужно и глупо.

Что за цп у тебя?
А вообще хотелось бы конфигурацию узнать =)

Да вы пипец упоротые тут x____x

А теперь если подумать головой:
Меньше фпс => меньше посылаемых апдейтов => меньше трафика генерируется => меньше шанс получить чоке.
Пруф: sys_ticrate 30, fy_pool_day, 14 ботов. choke внезапно 0.




Тогда зачем вообще говоришь о том, в чем не шаришь нифига?



Эта неловкая ситуация называется loss, а не чоке, обсосали уже в предыдущем посте.


Мнение специалиста, не разирающемся в рейтах, даже после подробного разжевывания, очень важно для нас, ага.
Вся инфа и простейшая формула есть в моем предыдущем посте. Если мозгов не хватает понять, что при увеличении делителя частное уменьшается, то вам надо в третий класс начальной школы.



Я писал вот что:

Если у тебя ютуб показывает на 1 мбитном канале, то он будет показывать и на 10 мбитах, при этом кол-во получаемого трафика не поменяется.
Если у тебя трафик сервера влезает в 5 мбит, то он влезет и в 20 мбит, при этом кол-во передаваемого трафика не поменяется.
Если у тебя пакетик с веществом влезает в карман, то он влезет и в походный рюкзак, при этом занимаемый им объем не поменяется.
Теперь ясно?

Дальше не комментирую, ибо бред полный. Идем учить матчасть.

berq,
Ок, лосс это потеря, а чок....это...
объясни что такое чок и как его вызвать, я и рейты попробывал разные, и канал загружал и все одно - их нету.


лень, но я возьму на заметку, что я днина безграмотная.

Как вызвать: поставить sv_minrate 2000 и sv_maxrate 2000

Что это такое - уже пытался объяснить:


Если не понятно - накидал график в паинте


Это информация об отсылке данных двум клиентам на сервере
У клиента1 апдейтрейт 101 (значит апдейты посылаются каждые 1/101 = 10 мсек) и рейт 10000
У клиента2 апдейтрейт 50 (значит апдейты посылаются каждые 1/50 = 20 мсек) и рейт 20000
На оси Х время в миллисекундах
Красные точки - момент отсылки апдейтов
Красные циферки - сколько байт было послано
Зеленые циферки - сколько времени нельзя посылать следующий апдейт, чтобы не нарушить политику рейтов, вычисляется как [байт_отправлено] / [рейт], назовем это "временем молчания"
Зеленая полоска - это отображение зеленой циферки на оси времени.
Розовые точки - это когда сервер хочет послать следующий апдейт (исходя из updaterate клиента)
Если сервер хочет послать апдейт (розовая точка) раньше, чем кончилось "время молчания" (зеленая полоска), начинается choke (оранжевая полоска)
choke продолжается до тех пор, пока сервер не пошлет следующий апдейт, а сделать он это сможет только когда кончится время молчания.

В момент генерации апдейта, если было choke, в пакет пишется мессага svc_choke; назовем такой пакет "чокнутым"
на клиенте в net_graph 3 отображается количество "чокнутых" пакетов из последних ста принятых.