Ядро с 1000 Hz

вот ты надоел уже. это не частота процессора. тебе зачем 1000?

Походу не встало ядрышко.

Timer Frequency
Timer
Процессора

описался, чтоб игровой сервер, запущенный под линуксом, выдавал 1000 ФПС

Игровой _сервер_ не может выдавать FPS в принципе. Потому что он не рисует кадры.

дружбан, пожалуйста, не отходи от сабжа :)

Слишком толсто. Кого тут надо скастовать для бана?

тебе это друганы рассказали наш секрет, как мы лучшие сервера поднимаем? за бесплатно?

описался, чтоб игровой сервер, запущенный под линуксом, выдавал 1000 ФПС

Забаньте уже этого клоуна.

Вообще у игрового сервера есть понятие FPS, но к частоте внутреннего системного таймера оно не имеет отношения. Тем более давно есть HPET.

Какое готовое rt ядро для debian 6 из репов имеет Timer frequency 1000 Гц?

Собери сам, чего ты. Там просто.

Вообще у игрового сервера есть понятие FPS, но к частоте внутреннего системного таймера оно не имеет отношения.

Frames Per Second на _сервере_?! И что оно означает?

пробовал, Не могу поменять ядро с linux 3.3.4

> Игровой _сервер_ не может выдавать FPS в принципе. Потому что он не рисует кадры.

забей. ему уже половиной лора пытались объяснить в предыдущих темах, но он свято верит, что частота таймера — это и есть частота процессора. и мало того, что процессор сервера рисует кадры клиентам, так он ещё и будет рисовать строго кадр в такт (ведь ядро же rt).

Fail Per Second же

в данной ситуации я не просил мне «что-то объяснять половиной лора», я попросил дать ссылку на ядро с частотой таймера в 1000 Hz

дружбан, пожалуйста, не отходи от сабжа :)

Ок.

• Linux - уже довольно давно tickless kernel по умолчанию во всех дистрибутивах. С тех пор смысла в 100Hz - 250Hz - 300Hz - 1000Hz нет.
• На игровом сервере нет смысла от RT.

Сервер имеет в себе модель игрового мира. Эта модель обсчитывается n раз в секунду. Вот текущий квант времени и зовётся «фреймом», соответственно FPS это частота пересчёта состояния мира.

а чего 1000? ставь миллион, будь мужыком

Iceland

Про rt ничего не знаю, а насчет Timer frequency = 1000 HZ, то вот:

http://liquorix.net/debian/pool/main/l/linux-liquorix/

или там же, но ядро по-старее:

http://liquorix.net/debian/pool/past/l/linux-liquorix/

Есть еще ядро c pf патчами:

http://kernel.night-leshiy.ru/

Правда я не уверен, что они встанут на debian 6, но ты можешь скачать исходники, подправить зависимости и в open build service (OBS) собрать пакет для Debian 6.

Хм, вот нашел еще ссылку на старые ядра liquorix. Брать тут.

Пробуй. Варианты есть. Можешь также собрать ядро сам.

Ты на этом форуме исключительно позоришься. У тебя сервер 1000 ФПС выдавать должен, а когда тебе на это указывают ты начинаешь просить не отходить от темы, то у тебя timer==процессор... Изыди.

> в данной ситуации я не просил мне «что-то объяснять половиной лора», я попросил дать ссылку на ядро с частотой таймера в 1000 Hz

юноша, ты на ЛОРе. пора бы понять, что здесь тебе ответят не то, что ты спрашивал, а то, что тебе необходимо.

Сервер имеет в себе модель игрового мира. Эта модель обсчитывается n раз в секунду. Вот текущий квант времени и зовётся «фреймом», соответственно FPS это частота пересчёта состояния мира.

Ок. Ответ принимается. Но тем не менее даже такие FPS имеют мало смысла, так как очевидно, что даже если некий глобальный таймер и дёргается 1000 раз в секунду, далеко не все объекты игрового мира будут пересчитываться 1000 раз в секунду. В частном случае, на карте без динамических объектов вообще, сервер будет ничего не делать 1000 раз в секунду.

Возвращаясь к теме ведра: с tickless kernel можно дёргать таймером и 10000 раз в секунду, если железо вывозит.

1) Кто сказал, что такое есть?
2) Кто сказал, что оно нужно?

Кстати насчёт tickless: я слышал, что с ним плохо работает CFS и автогруппировка задач. Это правда?

Ну в играх с довольно небольшим количеством динамических объектов, типа квейков <= 3, из объектов надо только игроков пересчитывать, можно уложиться в тысячу раз в секунду.

он не осилил в соседнем топике

ты просто не знаешь как работают старые ( а может и новые ) ферст персон шутер мультиплеер игры. количество фрэймов что обработает сервер очень важно. При количестве < 1000 тут тебе и едущие боксмодели игроков (когда на сервере игроков > 5-6), и в принципе не адекватная обработка событий мира. А если вдруг кто нибудь будет сидеть с fps (на клиенте) больше 100 (150-200-300 в старых играх - вообще не проблема) и будет ожидать от сервера информации о событиях не о последних ста кадрах, а больше - будет вообще грустно. В идеальном мире было бы достаточно 300, но так как всякие там синхронизации между пользователями с разным пингом и т.п. обсчет тысячи - очень важная тема.

но это не отменяет что топик стартер нуб, и не понимает что в линуксе что бы сделать это парится не нужно.

А, тогда ладно.

Кстати насчёт tickless: я слышал, что с ним плохо работает CFS и автогруппировка задач. Это правда?

Без понятия.

> А если вдруг кто нибудь будет сидеть с fps (на клиенте) больше 100 (150-200-300 в старых играх - вообще не проблема) и будет ожидать от сервера информации о событиях не о последних ста кадрах, а больше - будет вообще грустно.

какая разница, сколько сотен фпс у клиента, если пинг ≈10—50мс (≈20—100 синхронизаций/сек)? и да, клиент обычно ожидает не н последних дискретных кадров-состояний, а состояние «видимых» объектов на момент синхронизации (м.б. с вектором изменения состояния, с помощью которого клиент отрисует переход объекта из предыдущего состояния в текущее и просчитает его последующие изменения до следующей синхронизации).

ты на ЛОРе. пора бы понять, что здесь тебе ответят не то, что ты спрашивал, а то, что тебе необходимо.

Ага: живя MS-way'ем, тут только стремятся к UNIX-way'ю ;)

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

Кстати, гугл утверждает, что tickless не увеличивает частоту, он её наоборот уменьшает когда система простаивает. Это из соображений энергосбережения сделано.

Кстати, гугл утверждает, что tickless не увеличивает частоту, он её наоборот уменьшает когда система простаивает. Это из соображений энергосбережения сделано.

Нет. С tickless частота и не увеличивается и не уменьшается. Её вообще нет как таковой. Просто прерывание ставится на время ближайшего по сработке таймера. Это если очень упрощённо...

Спасибо тебе.

разница в том, что например игры на движке gold source(hl1, cs <= 1.6) очень сильно зависят от фпс на клиенте, и он действительно ждет этих самых 300 с сервера. если что он конечно рисует примерно. но там реально большие проблемы из за этого. когда хитбокс находится в «метре» от того места где ты видишь модель становится не весело :) просто не расчитывали тогда, что будет кто то так напрягать и сервер и клиент, когда это всё писалось.

Самое главное то, что все соременные дистрибутивные ядра собраны с tickless.

В SL Такое есть. Для обозначения задержек расчетов на сервере.

Ты опять начинаешь, шакал?

На самом деле, ТС прав. Вероятно, он хочет поднять сервер каэсочки, а он написан криво, без использования high-res timers и, видимо, использует слипы или какую-то фигню, и с таймером в 1000 герц работает быстрее.

По поводу tickless — он до сих пор работает крайне криво и частоту таймера нужно задавать при tickless. Проверено на Dingoo A320, при частоте 100-128 нормально, при 250 — оптимально (в ядре по умолчанию после того, как баг описал), а было с 1000 — сильно просаживалась производительность (железо-то не быстрое)

Это мало что значит.

Большая частота имеет смысл только на относительно быстром процессоре.

Может ты уже кого-нибудь попросишь тебе собрать ядро?) Именно для твоего компа и со всем фишками, что ты хочешь?

А то прям уже ждёшь очередного топика, и интересно, какой будет следующая проблема. Ещё можно договориться потестировать разные частоты и tickless, в сервере игры же есть встроенный бенчмарк? Ещё можно испробовать разные bfs|bfq) поле на паханное.

Tickless mode можно отключить параметром nohz=off. Правда, практического смысла в этом обычно нет, что бы там ни фантазировали некоторые упоротые оптимизаторы.

Ничего подобного, вот вчера только собирал tickless-ядро с поддержкой hpet и частоту поставил 100 Hz.

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/time.h>


#define USECREQ 250
#define LOOPS   1000

void event_handler (int signum)
{
 static unsigned long cnt = 0;
 static struct timeval tsFirst;
 if (cnt == 0) {
   gettimeofday (&tsFirst, 0);
 } 
 cnt ++;
 if (cnt >= LOOPS) {
   struct timeval tsNow;
   struct timeval diff;
   setitimer (ITIMER_REAL, NULL, NULL);
   gettimeofday (&tsNow, 0);
   timersub(&tsNow, &tsFirst, &diff);
   unsigned long long udiff = (diff.tv_sec * 1000000) + diff.tv_usec;
   double delta = (double)(udiff/cnt)/1000000;
   int hz = (unsigned)(1.0/delta);
   printf ("kernel timer interrupt frequency is approx. %d Hz", hz);
   if (hz >= (int) (1.0/((double)(USECREQ)/1000000))) {
     printf (" or higher");
   }       
   printf ("\n");
   exit (0);
 }
}

int main (int argc, char **argv)
{
 struct sigaction sa;
 struct itimerval timer;

 memset (&sa, 0, sizeof (sa));
 sa.sa_handler = &event_handler;
 sigaction (SIGALRM, &sa, NULL);
 timer.it_value.tv_sec = 0;
 timer.it_value.tv_usec = USECREQ;
 timer.it_interval.tv_sec = 0;
 timer.it_interval.tv_usec = USECREQ;
 setitimer (ITIMER_REAL, &timer, NULL);
 while (1);
}

Вот этот код при исполнении показывал частоту прерываний в 4000+ Hz

да, машина неслабая, SixCore Xeon E

далеко не все объекты игрового мира будут пересчитываться 1000 раз в секунду

Да и смысла-то от этого особо нет.