Помогите. sv ms var(нижняя строчка net_graph 1) красная.

[52bit]

Всем привет. Пытаюсь месяц решить проблему, нижняя строчка net graph там где sv ms var, цифры должны там меняться очень быстро, но у меня они меняются очень медленно и порой эта строчка становится красной(начинает фризить кс) . Раньше всё было норм, все цифры менялись быстро, пытался найти решение проблемы, увы, ни чистка кеша стима, ничего не помогло. Может была у кого такая проблема?
Комп покупался в ноябре, комп не слабый i5 8500, ОЗУ 16гб, Nvidia 1060 6gb. Интернет тоже хороший.
http://www.imageup.ru/img72/3357844/fzqdnff_m7c.jpg

[tmwichy]

Можете установить программу для проверки нагрузки? Как и скриншот нетграфа?

[52bit]

Originally posted by tmwichy:

Можете установить программу для проверки нагрузки? Как и скриншот нетграфа?

Подробнее.

[tmwichy]

fps — тут всё понятно,  кол-во кадров в секунду
ping — ваш реальный пинг на сервере
tick — это тикрейты сервера
up — кол-во пакетов, которое вы отправляете (в секунду)
cmd — кол-во пакетов, которое вы принимаете (в секунду)
Строка ниже — это то место где Вы играете
loss — процент утерянных пакетов (чем больше, тем хуже)
choke — процент пакетов, которые Вы не смогли получить от сервера (чем больше, тем хуже)
sv — кол-во миллисекунд которое потребовалось для обработки ваших пакетов
+- — это погрешность параметра sv.
var — fps сервера

[52bit]

Originally posted by tmwichy:

fps — тут всё понятно,  кол-во кадров в секунду
ping — ваш реальный пинг на сервере
tick — это тикрейты сервера
up — кол-во пакетов, которое вы отправляете (в секунду)
cmd — кол-во пакетов, которое вы принимаете (в секунду)
Строка ниже — это то место где Вы играете
loss — процент утерянных пакетов (чем больше, тем хуже)
choke — процент пакетов, которые Вы не смогли получить от сервера (чем больше, тем хуже)
sv — кол-во миллисекунд которое потребовалось для обработки ваших пакетов
+- — это погрешность параметра sv.
var — fps сервера

Это всё я читал, но решение своей проблемы не нашёл. Раньше месяц назад было всё норм, цифры всегда менялись быстро и были белые, теперь очень медленно и порой строчка становится красной.

[rageful_me]

Originally, it was considered respectable to have a var of less than 1, reasonable to have it spike as high as 2, but pretty much horrible to have a variance remain above 2 for any length of time. What would be the equivalent values for the three new measurements (sv, +-, and var)?

For a 64-tick server as long as sv value stays mostly below 15.625 ms the server is meeting 64-tick rate requirements correctly. For a 128-tick server as long as sv value stays mostly below 7.8 ms the server is meeting 128-tick rate requirements correctly. If standard deviation of frame start accuracy exceeds fractions of millisecond then the server OS has lower sleep accuracy and you might want to keep sv simulation duration within the max duration minus OS sleep precision (e.g. for a 64-tick Windows server with sleep accuracy variation of 1.5 ms you might want to make sure that server simulation doesn’t take longer than 15.625 minus 1.5 ~= 14 ms to ensure best experience).

Попробуй поменять тикрейт обратно на 64. Вроде это настраивается через параметры запуска.

[52bit]

Originally posted by rageful_me:

Originally, it was considered respectable to have a var of less than 1, reasonable to have it spike as high as 2, but pretty much horrible to have a variance remain above 2 for any length of time. What would be the equivalent values for the three new measurements (sv, +-, and var)?

For a 64-tick server as long as sv value stays mostly below 15.625 ms the server is meeting 64-tick rate requirements correctly. For a 128-tick server as long as sv value stays mostly below 7.8 ms the server is meeting 128-tick rate requirements correctly. If standard deviation of frame start accuracy exceeds fractions of millisecond then the server OS has lower sleep accuracy and you might want to keep sv simulation duration within the max duration minus OS sleep precision (e.g. for a 64-tick Windows server with sleep accuracy variation of 1.5 ms you might want to make sure that server simulation doesn’t take longer than 15.625 minus 1.5 ~= 14 ms to ensure best experience).

Попробуй поменять тикрейт обратно на 64. Вроде это настраивается через параметры запуска.

-tikrate 64, тип команду поставить?

[rageful_me]

Думаю достаточно убрать -tickrate 128. 64 - это стандартный тикрейт для локального сервера.

[52bit]

Originally posted by rageful_me:

Думаю достаточно убрать -tickrate 128. 64 - это стандартный тикрейт для локального сервера.

Не помогло(((

[rageful_me]

Кинь новый скрин. 25 мс на фрейм это слишком много. Твоя машина максимум сможет вытянуть 1000/25 = 40 фреймов в секунду

[52bit]

Originally posted by rageful_me:

Кинь новый скрин. 25 мс на фрейм это слишком много. Твоя машина максимум сможет вытянуть 1000/25 = 40 фреймов в секунду

http://www.imageup.ru/img72/3357929/ksdtfskm-eq.jpg

[52bit]

Originally posted by rageful_me:

Кинь новый скрин. 25 мс на фрейм это слишком много. Твоя машина максимум сможет вытянуть 1000/25 = 40 фреймов в секунду

Я не понимаю, в чём может быть проблема....(( Раньше всё норм было.

[rageful_me]

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

[52bit]

Originally posted by rageful_me:

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

Я на фейсете сейчас играл. Как мне с тобой связаться?

[rageful_me]

Для тикрейта 128 сервер должен тратить на обработку одного фрейма не больше чем 1000/128 = 7.8125 мс. Количество времени на фрейм зависит от текущего онлайна. Данный сервер не справляется с нагрузкой - это приводит к нестабильному тикрейту. Попробуй зайти на другой сервер.

[52bit]

Originally posted by rageful_me:

Дли тикрейта 128 сервер должен тратить на обработку одного фрейма не больше чем 1000/128 = 7.8125 мс. Количество времени на фрейм зависит от текущего онлайна. Данный сервер не справляется с нагрузкой - это приведет к нестабильному тикрейту. Попробуй зайти на другой сервер.

http://www.imageup.ru/img72/3357939/uru7ziuhuk4.jpg