Linux за българи: Форуми

Значи използвам цс 1.6 сървър билд 4617 и 4883 но процесора забързва като задам ма sys_tickrate повече от 1080 защо така ??? Ядрото ми е компилирано на 1000 херца ??? Идеи ???

Кво кво :)
Я дефинирай забързва и как така компилира кернела на 1000Hz :)

Кво кво :)
Я дефинирай забързва и как така компилира кернела на 1000Hz :)

Играта в сървъра забързва и компилиране с такива настроики
http://virtual.new.bg/forum/viewtopic.php?f=110&t=1107

Защо увеличав броя на tics за секунда, по добре е да махнеш излишните процеси които отнемат от така наречените tics. Или да сложиш 2 ядрена машина.
В опциите за компилация няма нищо ускоряващо освен изключването на kernelhacking. Другото е таймера да е с висока резолюция (той определя и броя задачи ticks за една секунда).
Като дигнеш броят над 1000 тогава трошиш зависимоста от таймера, при което един процес неможе да бъде прекъснат след 100 микросекунди и да се отдаде време на друг процес. Това вече се определя софтуерно, но в този случай се появяват много други проблеми, тоест процеса на CS може да заеме самоволно - без да може да бъде прекъснато от хардуера по голямо време то 80-100 милисекунди. Това може да доведе до 2-3 милисекундно изпълнение на този процес до изпълнение на 'последна' функция преди прекъсването. Същото обаче може да го направи и всеки друг процес с по дълга (времемка имам предвид) функция. Така че това не е решение, освободи се от всички други процеси, остави само мрежа, ssh, и CS сървера, по-добро решение е по-мощна машина.
Приятна игра!

Има един бърз хак, има :)

По принцип ядрото използва няколко task scheduling политики, нищо че дефолтската е SCHED_OTHER, която ползва time slicing със всичките в случая негативни последствия от сорта на това че други процеси които не заслужават, крадат процесорно време от твоя процес.

За щастие, в по-новите ядра, task scheduling policy-то може да се set-ва per-process, има и tool-че за това, наречено chrt. Та с въпросното първо сменяш policy-то на SCHED_FIFO (chrt -f -p pid)

SCHED_FIFO работи на съвсем различен принцип от SCHED_OTHER (тези с по-висок приоритет ВИНАГИ се изпълняват докато не срещнат блокираща операция или докато някое хардуерно прекъсване не ги preempt-не). Освен това, когато SCHED_FIFO процес се "събуди", дори приоритетът му да е 0, ако на процесорът в момента върви някакъв SCHED_OTHER процес, той винаги се preempt-ва и се изпълнява SCHED_FIFO процеса.

Та втората стъпка е да вдигнеш приоритета на сървъра, примерно на 50 (chrt -p 50 pid).

Така ще си гарантираш голяма част от процесорното време само за твоя процес...и остава да се надяваш че ще му е достатъчно.

В ядрото което си компилирал няма нищо дадено за schedul-а както ко обяснява gate3way. Става този хак но не забравяй че е хак и може да има неочаквани последствия за други процеси. И от мене един трик, пробвай с RTAI но ще трябва пачване на ядрото, и доста трикове за да го подкараш в реално време. Ако не стане с опашките (както gate3way го е описал) на задачи чак тогава копай в RTAI за реално време, доста четене трябва и разбирана за кернела, кое, какво, що

Абе няма толкова страшно според мен, в смисъл това е гейм сървър, не някаква симулация на първите няколко секунди след големия взрив :)  Очаква се да има достатъчно много I/O операции, които ще отказват процеса от процесора - писане/четене по сокети разни, такива работи, надали толкова няма да остане процесорно време за останалите процеси. Ма знам ли.

Наскоро апропо се "запознах" с една система с RT ядро, беше точно защото е някакъв гейм сървър, много се зачудих, но ми се обясни че иначе насичало и лагвало. Нямам идея, щото никога не съм се занимавал с такива неща, но предполагам има някаква логика.

Абе няма толкова страшно според мен, в смисъл това е гейм сървър, не някаква симулация на първите няколко секунди след големия взрив :)  Очаква се да има достатъчно много I/O операции, които ще отказват процеса от процесора - писане/четене по сокети разни, такива работи, надали толкова няма да остане процесорно време за останалите процеси. Ма знам ли.

Наскоро апропо се "запознах" с една система с RT ядро, беше точно защото е някакъв гейм сървър, много се зачудих, но ми се обясни че иначе насичало и лагвало. Нямам идея, щото никога не съм се занимавал с такива неща, но предполагам има някаква логика.

Съгласен съм ама обикновенно не ги ползват само за игрови свр. Друго е че за това сърверче не се знае какво точно прави, виждал съм го без играчи да вдига 100% на моменти.
А за RT е мнооого зор + писане малко на C и маса пачове за да се подкарат кернелски функции през опашките в реално време - а и забива яко без логове ако сгафиш нещо с релното време. Но иначе рутер съм пуснал на това, върви с скорост 5м/сек с резолюция 1микрон и точност 25 микрона по 6 оси  http://www.linuxcnc.org/ ($2) обаче събран от Gentoo със мои драйвери и хардуер. Ама зор беше да тръгне.