Начал я писать эту статью от нечего делать....
Смотрим параметры планировщика ядра:
Этот параметр в нано-секундах, в нашем случае время переключения ядра между задачами 12мс. Чтобы в ходе работы планировщика ваша задача (HLDS) не прерывалась ("лагала"), необходимо чтобы количество прерываний (HLDS) было кратно этому значению (делилось без остатка).
Попробуем увязать полученные мной эмпирические данные, со средним значением FPS = 100... Придумаем какую-нибудь формулу.
Минимальный FPS сервера (при 12 мс планировщика) = (1 / 0.012) * 100 FPS * 0,1 (100 мс) = 833,333333 FPS. Что-то похожее на правду... 8,3к много, поэтому придумаем константу
Оптимальный вариант для расчетного значения (FPS = 833,333333) ближайшее целое кратное 12 - будет 6 (т.е. 600 FPS) и далее, все числа умноженные на 2:
Как раз частота обновления стандартного игрового монитора. Прим.: Какого монитора?????...
Что ты несешь...
Идем дальше.
Получаем
Вот тут, выложили параметры ядра VDS Арены:
Повторяем расчет:
Минимальный FPS сервера для игроков (100FSP) =
Получается, серверу Арены требуется меньшее количество FPS... В процессе написания статьи этот факт меня ввел в некоторое замешательство... 
Смотрим дальше, сколько кадров обрабатывается за время работы планировщика:
Арена
Интуиция мне подсказывает, что 1,2 кадра, это сильно хуже чем 2, потому что это не целое число. Для идеального соотношения в 1 кадр на 1 прерывание (HLDS), во втором случае нам нужно просто умножить результат на 2:
И переформулировав условие в первом абзаце на: "Чтобы в ходе работы планировщика ваша задача (HLDS) не прерывалась ("лагала"), необходимо чтобы количество прерываний было кратно этому значению (делилось без остатка) и чтобы за время работы планировщика обрабатывалось целое число кадров", пытаемся выполнить перерасчет первого варианта:
Для того чтобы за 1 прерывание обрабатывался 1 кадр при 100FPS, меняем:
Таким образом мы получаем, минимальный FPS (для обработки 1 кадра на 1 прерывание HLDS) =
Красивая цифра...
Минуточку...., А что мы получаем взамен уменьшения времени работы планировщика вдвое? Херня какая-то...
У нас стрельба точно лучше Арены... Что-то я упустил...
Вася 
Начинаем заново строить теорию...
Максимальное количество прерываний генерируемое всеми пользователями: 32*102 = 3264...
Округлим до 4000 (не спрашивайте, так надо для UDP, для TCP я бы удвоил и округлил до 10к). Это прерывания ядра: сетевая карта <-> HLDS.
Необходимое время переключения планировщика:
Минимальный FPS сервера, для соотношения 4 прерываний ядра на 1 сетевой FPS: 1 / (4 * 0,00025) = 1000 FPS. Оптимально для 2CPU и более...
Устанавливаем
Перезапускаем сервер, тестируем стрельбу...
Отписываемся, минусуем и ругаем
Смотрим параметры планировщика ядра:
Код:
root@k36895:~# sysctl kernel.sched_latency_ns
kernel.sched_latency_ns = 12000000Попробуем увязать полученные мной эмпирические данные, со средним значением FPS = 100... Придумаем какую-нибудь формулу.
Минимальный FPS сервера (при 12 мс планировщика) = (1 / 0.012) * 100 FPS * 0,1 (100 мс) = 833,333333 FPS. Что-то похожее на правду... 8,3к много, поэтому придумаем константу
100мс это время "интерполяции", которая зависит от "мощности" железа. Для любого VDS, предположим, что это предельная величина, а на реальном современном железе эта константа близка к 1.Оптимальный вариант для расчетного значения (FPS = 833,333333) ближайшее целое кратное 12 - будет 6 (т.е. 600 FPS) и далее, все числа умноженные на 2:
12, 24, 48.... Если выберем 6 - получим около 100 * ( 6 / 8,3 ) = 72 FPS на клиенте, что малова-то... Остается 12 и более, при 12 получим 100 * ( 12 / 8,3 ) = 144,5 FPS Как раз частота обновления стандартного игрового монитора. Прим.: Какого монитора?????... Что ты несешь...Идем дальше.Получаем
sys_ticrate = 1200. Попробуем сделать сравнительный анализ...Вот тут, выложили параметры ядра VDS Арены:
kernel.sched_latency_ns = 20000000Повторяем расчет:
Минимальный FPS сервера для игроков (100FSP) =
(1 / 0.02) * 100 * 0,1 = 500 FPS. Получается, серверу Арены требуется меньшее количество FPS... В процессе написания статьи этот факт меня ввел в некоторое замешательство... Смотрим дальше, сколько кадров обрабатывается за время работы планировщика:
Арена
100 / (1 / 0.02) = 2 кадра. В первом варианте: 100 / (1 / 0.012) = 1,2.Интуиция мне подсказывает, что 1,2 кадра, это сильно хуже чем 2, потому что это не целое число. Для идеального соотношения в 1 кадр на 1 прерывание (HLDS), во втором случае нам нужно просто умножить результат на 2:
sys_ticrate = 1000.И переформулировав условие в первом абзаце на: "Чтобы в ходе работы планировщика ваша задача (HLDS) не прерывалась ("лагала"), необходимо чтобы количество прерываний было кратно этому значению (делилось без остатка) и чтобы за время работы планировщика обрабатывалось целое число кадров", пытаемся выполнить перерасчет первого варианта:
Для того чтобы за 1 прерывание обрабатывался 1 кадр при 100FPS, меняем:
sysctl kernel.sched_latency_ns=10000000Таким образом мы получаем, минимальный FPS (для обработки 1 кадра на 1 прерывание HLDS) =
(1 / 0.01) * 100 * 0.1 = 1000.Красивая цифра...
Минуточку...., А что мы получаем взамен уменьшения времени работы планировщика вдвое? Херня какая-то...
У нас стрельба точно лучше Арены... Что-то я упустил...А упустил я количество пользователей на сервере и общее число прерываний необходимое для обработки всех их запросов, а также попутал сетевой FPS (cl_cmdrate) и графической карты
Вася Начинаем заново строить теорию...
Максимальное количество прерываний генерируемое всеми пользователями: 32*102 = 3264...
Округлим до 4000 (не спрашивайте, так надо для UDP, для TCP я бы удвоил и округлил до 10к). Это прерывания ядра: сетевая карта <-> HLDS.
Необходимое время переключения планировщика:
0,25 мс. Меняем: sysctl kernel.sched_latency_ns=250000Минимальный FPS сервера, для соотношения 4 прерываний ядра на 1 сетевой FPS: 1 / (4 * 0,00025) = 1000 FPS. Оптимально для 2CPU и более...
Устанавливаем
sys_ticrate = 1000Перезапускаем сервер, тестируем стрельбу...
Отписываемся, минусуем и ругаем
Последнее редактирование:
