автовыдача Rate для Соурсмода в CS:S
Не знаю как вы там измеряли, у меня хоть в нетграфе, хоть по счетчику трафа, всё сходится и всё работает.
Не думаю что разрабы контры совсем уж дебилы и писали эти ключи непонимая принципа работы сети.
Не думаю что разрабы контры совсем уж дебилы и писали эти ключи непонимая принципа работы сети.
Уж незнаю как там дела в Source Classic, а в Source 2007 U1 хрень полнейшая.
Привожу простейший пример: запустил на своей тачке сервер L4D2, sv_min/maxcmdrate 30, sv_min/maxupdaterate 13, у клиента и cmdrate и updaterate по 100/s. Захожу на сервер и вижу следующую картину:
Обратите внимание на пинги в статистике и в нетграфе.
Далее через консоль у клиента ставлю cl_cmdrate 30, cl_updaterate 13, т.е. как у сервера и вижу следущее:
И замечаем ощутимую разницу в пинге, причём и в нетграфе и в статистике. Отсюда вопрос, если движок лефта не способен одавать и принимать более 30 пакетов/с, зачем клиентам дали такую волю в рейтах?
Итог: из и эксперимента я не вижу ничего хорошего в том чтобы у клиентов рейты были больше серверных, т.е. плагин нужный.
Привожу простейший пример: запустил на своей тачке сервер L4D2, sv_min/maxcmdrate 30, sv_min/maxupdaterate 13, у клиента и cmdrate и updaterate по 100/s. Захожу на сервер и вижу следующую картину:
Обратите внимание на пинги в статистике и в нетграфе.
Далее через консоль у клиента ставлю cl_cmdrate 30, cl_updaterate 13, т.е. как у сервера и вижу следущее:
И замечаем ощутимую разницу в пинге, причём и в нетграфе и в статистике. Отсюда вопрос, если движок лефта не способен одавать и принимать более 30 пакетов/с, зачем клиентам дали такую волю в рейтах?
Итог: из и эксперимента я не вижу ничего хорошего в том чтобы у клиентов рейты были больше серверных, т.е. плагин нужный.
0zon, То что в нетграфе и в статистике называется "ping", на самом деле никакой не пинг, а приблизительная внутриигровая задержка, посчитанная каким-то хитрым способом.
Ощутимой разницы в "пинге" тоже нет. Вы представляете что такое 9 мсек? (для сравнения, у 75 Гц монитора картинка обновляется раз в 13 мсек).
Теперь давайте попробуем реальную задержку посчитать более объективно:
1) реальный cmdrate=30 => интервал отправки cmd пакетов = 1/30 = 33мсек => средняя задержка от действия клиента до отправки cmd пакета на сервер равна 33/2 = 16.5 мсек
2) реальный updaterate=13 => интервал отправки upd пакетов = 1/13 = 76 мсек => средняя задержка от получения сервером cmd пакета до отправки ответного upd пакета = 76/2 = 38 мсек
Итого, только в очередях на ожидание отправки пакетов мы теряем 54.5мсек. Вы все еще верите в "пинг", который пишут в статистике? :)
Я на этих двух скриншотах увидел вот что: серверные квары, контролирующие рэйты (sv_maxupdaterate/sv_maxcmdrate), работают нормально - реальные cmdrate и updrate не изменились при изменении клиентских рэйтов.
Итого: Имхо, менять игроку рэйты, ради того чтобы циферка в поле "латенси" (которая все равно показывает какую-то фигню) была поменьше - это слишком.
Ощутимой разницы в "пинге" тоже нет. Вы представляете что такое 9 мсек? (для сравнения, у 75 Гц монитора картинка обновляется раз в 13 мсек).
Теперь давайте попробуем реальную задержку посчитать более объективно:
1) реальный cmdrate=30 => интервал отправки cmd пакетов = 1/30 = 33мсек => средняя задержка от действия клиента до отправки cmd пакета на сервер равна 33/2 = 16.5 мсек
2) реальный updaterate=13 => интервал отправки upd пакетов = 1/13 = 76 мсек => средняя задержка от получения сервером cmd пакета до отправки ответного upd пакета = 76/2 = 38 мсек
Итого, только в очередях на ожидание отправки пакетов мы теряем 54.5мсек. Вы все еще верите в "пинг", который пишут в статистике? :)
Я на этих двух скриншотах увидел вот что: серверные квары, контролирующие рэйты (sv_maxupdaterate/sv_maxcmdrate), работают нормально - реальные cmdrate и updrate не изменились при изменении клиентских рэйтов.
Итого: Имхо, менять игроку рэйты, ради того чтобы циферка в поле "латенси" (которая все равно показывает какую-то фигню) была поменьше - это слишком.
Я верю лишь нетграфу, а в нем разница в 31мс и это не мало.
Думаю полемику можно прекратить, и у вас и у меня лишь догадки и предположения, я так понимаю что вы не разработчик движка сурс и поэтому не сможете мне ничего доказать равно как и я вам. (Я о том что завышенные клиентские рейты никак не сказываются ни на самих клиентах ни на сервере)
Думаю полемику можно прекратить, и у вас и у меня лишь догадки и предположения, я так понимаю что вы не разработчик движка сурс и поэтому не сможете мне ничего доказать равно как и я вам. (Я о том что завышенные клиентские рейты никак не сказываются ни на самих клиентах ни на сервере)
1) Тема называется автовыдача Rate для Соурсмода в CS:S, давайте всётаки общаться по ней и не уходить в сторону. CS:S это Counter-Strike Source и другого быть не может.
2) Задержка - смотрится за сколько отправленный сервером пакет пришёл и обработался клиентом + за сколько отправленный клиентом пакет дошёл до сервера и обработался им. Далее делится на 2 и получается задержка, которая равна среднему значению пинг плюс время, затраченное на его обработку.
Если пинг значительно расходится с задержкой, значит нужно повышать фпс, тик рейт, апдейт рейты, pingbooster 3 у кого Linux и.т.п.
3) Как я сказал раньше, разрабы всётаки не балбесы...
2) Задержка - смотрится за сколько отправленный сервером пакет пришёл и обработался клиентом + за сколько отправленный клиентом пакет дошёл до сервера и обработался им. Далее делится на 2 и получается задержка, которая равна среднему значению пинг плюс время, затраченное на его обработку.
Если пинг значительно расходится с задержкой, значит нужно повышать фпс, тик рейт, апдейт рейты, pingbooster 3 у кого Linux и.т.п.
3) Как я сказал раньше, разрабы всётаки не балбесы...
Имхо, вера непонятно во что - это не очень хорошо. Объясню свою точку зрения: И до и после смены рэйтов клиент получал и отправлял одно и то же количество пакетов. Т. е. смена рэйтов реально не повлияла на объем/частоту передачи данных. Почему тогда значительно уменьшилась циферка в поле "пинг"? (вопрос риторический)0zon писал(а):Я верю лишь нетграфу, а в нем разница в 31мс и это не мало.
Ок, на этом и закончим.0zon писал(а): я так понимаю что вы не разработчик движка сурс и поэтому не сможете мне ничего доказать равно как и я вам.
-
- Лейтенант
- Сообщения: 143
- Зарегистрирован: 02.01.2006
- Благодарил (а): 3 раза
- Поблагодарили: 4 раза
- Контактная информация:
Есть плагин правки рейтов на стороне клиентов под sm
- Вложения
-
- rate_enforcer.rar
- (2.32 КБ) 103 скачивания
- rate_enforcer.rar
- (2.32 КБ) 103 скачивания
При том, что из всех правИльных cvar'ов не работает только sv_minrate и Вы сами можете в этом убедиться. Если на сервере стоит sv_minrate 10000, Вы спокойно можете ставить rate 3500 и наслаждаться Вашим choke.the_crock писал(а):Не уловил логики, причем тут sv_minrate?Yogurt писал(а):Если через sm_rates это не видно, то по нетграфу это очень даже видно))
По сути "правильщики" рейтов нужны только потому что не работает серверный cvar sv_minrate
В статистике пишется задержка (latency), а в нетграфе пинг (ping) и они не должны быть равны, а различаться примерно в 2 раза.the_crock писал(а):0zon, То что в нетграфе и в статистике называется "ping", на самом деле никакой не пинг, а приблизительная внутриигровая задержка, посчитанная каким-то хитрым способом.
Т.к. задержка это время прохождения пакета от клиента до сервера, а пинг - время прохождения пакета туда-обратно (пинг-понг :D ).
ТрололололоSAS123 писал(а):Есть плагин правки рейтов на стороне клиентов под sm
Yogurt про задержку, ваша теория противоречит моей :)
Вы уверены что задержка это не пинг+время обработки?
Вы уверены что задержка это не пинг+время обработки?
Мдееее тогда бы пинг был ниже задержки не так ли?
Если подробнее - время генерации пакета и отправки его на сервер, измеряется в миллисекундах. Зависит не только от сетевых настроек, но и от характеристик железа. То есть если процессор "тугодум", то пакет будет генерироваться дольше => задержка возрастет.Yogurt писал(а):Т.к. задержка это время прохождения пакета от клиента до сервера
Ну да, пинг и получается меньше.
Нажми пуск - выполнить -
где ya.ru - адрес сервера
И тебе выведется пинг.
А если посмотреть через хлсв или ввести пинг в консоль игры, или посмотреть в нетграфе - то там выводится задержка.
И она будет больше пинга.
У меня к примеру на серве при загрузке проца под 99% задержка становится в 8 раз больше пинга.
Т.е. если через ping -t ya.ru - то всреднем 7мс, а если в хлсв - то 55-60мс
Как только народ сваливает до 20 человек, хлсв становится 15-20мс
Далее если прописать pingboost 3, тикрейт 99, и разогнать проц, то задержка ещё снижается и стремится к пингу.
Нажми пуск - выполнить -
Код: Выделить всё
ping -t ya.ru
И тебе выведется пинг.
А если посмотреть через хлсв или ввести пинг в консоль игры, или посмотреть в нетграфе - то там выводится задержка.
И она будет больше пинга.
У меня к примеру на серве при загрузке проца под 99% задержка становится в 8 раз больше пинга.
Т.е. если через ping -t ya.ru - то всреднем 7мс, а если в хлсв - то 55-60мс
Как только народ сваливает до 20 человек, хлсв становится 15-20мс
Далее если прописать pingboost 3, тикрейт 99, и разогнать проц, то задержка ещё снижается и стремится к пингу.
в хлсв ты тоже яндекс пингуешь? :)
Трасерт в ХЛСВ много нагляднее чем traceroute. :)
Yogurt яндекс был для примера. Вместо него втыкаешь адрес своего или любого другого сервера, пинг до которого нужно определить
какие все непонятливые пошли...
какие все непонятливые пошли...
Мой вариант плагина для автоматического исправления рейтов
- Вложения
-
- Forcerate v1.0.rar
- (5.2 КБ) 96 скачиваний
- Forcerate v1.0.rar
- (5.2 КБ) 96 скачиваний