DE:Linux Kernel Optimierung HL1

From FrâG^.WIKI

Jump to: navigation, search

(English Version)

Dieser Artikel bezieht sich auf Game-Server.

Contents

Einleitung

Vorne weg möchte ich gleich sagen, dass hier vieles mit dem HowTo für den HL2 Kernel identisch ist. Dies gilt insbesondere für den Idler und Rescheduling Teil. Dieses Howto wurde hingegen auf den Betrieb von HL1 Servern mit Debian angepasst, verwendet ein anderes Patchset, und ist auf HL1 anstelle von HL2 Servern gerichtet.

Als Erstes sollte man sich klarmachen, was für einen Server man einrichten will. Soll es ein reiner CS (HL1) Server werden, oder sollen noch andere Programme darauf laufen. Insbesondere der gleichzeitige Betrieb von HL1 und HL2 Servern auf einem System ist nicht zu empfehlen, weil bei den meisten Kerneln eine der Serverarten nicht die volle Leistung entfalten kann. Meistens ist dies dann der HL1 Server. Eine Außnahme scheinen hier Kernel zu sein, in die der BFS Scheduler gepatched wurde. Aber auch er führt dann nicht zu 100% Stabilität.

Ein Performancekiller kann Metamod mit AMXMODX sein. Mit manchen Plugins erzeugen sie starke FPS Drops und erhöhen dazu auch noch stark den Verbrauch von CPU Leistung. Wenn ihr einen Warserver oder ähnliches einrichten wollt, verabschiedet euch also vom Gedanken diese Addons zu benutzen.

Im Weiteren sollte man sich bewusst machen, was Server FPS, sys_ticrate, fps_max und pingboost bedeuten. Server FPS sind die Netzwerkoperationen in der Sekunde. Gleichzeitig werden die abgelaufenden FPS für die Zeitberechnung des Servers genutzt. Bei HL1 Servern können sie im Gegensatz zu HL2 nicht höher als die Anzahl der Weltbildberechnung, die über die sys_ticrate gesteuert wird.
Pingboost verändert die Syscalls des Servers. Bei allen Varianten, bis auf pingboost 3, ist für die effektiv erreichten Server FPS und sys_ticrate das Limit bei ca 1000, egal, was man einstellt. Die effektiv erreichten ServerFPS/Tickrate könnt ihr euch anschauen, wenn ihr auf den Konsole "host_speeds 1" eingebt. Diese Anzeige ist wesentlich genauer, als die "stats" Ausgabe per RCON.
Ohne den Server zu hacken ist das Limit für fps_max immer 1000. Mit pingboost 3 wird das 1000er Limit für die sys_ticrate jedoch aufgehoben.
Wird jetzt eine sys_ticrate von über 1000 erreicht, egal wie stark sie schwankt, gibt der "stats" Befehl immer 1000 FPS aus, egal, welcher Wert überhalb der 1000 erreicht wurde.
Dadurch, dass in diesem Fall mehr als 1000 FPS in der Sekunde ablaufen, der Server aber dennoch davon ausgeht, dass maximal 1000 ablaufen können, ist für ihn eine Sekunde früher abgelaufen, als in der Echtwelt. Im Spiel selber merkt man dann eine "Beschleunigung"

Zurück zum Kernel:
Gute Kernel zeichnen sich dadurch aus, dass die eingestellte sys_ticrate auch relativ genau erreicht und gehalten wird. Ein 100% Übereinstimmen von eingestellt und erreicht wird es nie geben. Wenn man also sys_ticrate 1010 einstellt und Werte von 990-1010 erreicht ist dies ein sehr gutes Ergebnis.
Ein guter Kernel zeichnet sich also dadurch aus, dass der Server schon bei kleinen Werten der sys_ticrate oberhalb von 1000 beschleunigt, wenn man pingboost 3 benutzt.

Kernelübersicht

Eine Übersicht über gängige Kernel und Patche und ihre Einschränkungen. Pingboost kürze ich mit PB und sys_ticrate mit Tic ab. Sehr zu empfehlen für HL1 Server ist der BFS Scheduler/Patch. Er wurde zwar für Desktop Systeme geschrieben, mit ihm lassen sich aber im Moment HL1 Server am stabilsten und besten betreiben. Im Folgenden gehe ich davon aus, dass man den BFS Scheduler patched, gebe aber gleichzeitig mit an, wie man beim recompilen des Debian Kernels vorgeht.
Dazu noch eine kurze Übersicht über die gängigen Kernel.

2.6.26 Debian Stable

  • Stabil und einfach zu compilieren.
  • Erreicht mit PB 2 999-1000FPS, auch mit Spielern auf dem Server
  • PB 3 erreicht 1000 FPS ohne Spieler, jedoch kommt es zu FPS Drops, wenn gespielt wird. Er zeigt keine Beschleunigungseffeckte bei Tic 2500 und PB 3
  • Für den gleichzeitigen Betrieb von HL1 und HL2 nicht geeignet.

Vanilla (kernel.org)

  • Aktuelle Version 2.6.33.4
  • Erreicht ca 970 FPS mit PB2 und Spielern
  • 1000 mit PB3. Mit PB 3 und Tic 2500 keine Beschleunigung zu merken.
  • Sowohl mit PB 2, als auch 3 kommt es oft zu starken FPS Drops, die auch im Spielfluß bemerkbar sind. Im Moment nicht zu empfehlen.

RT Patch

  • Scheint die gleichen Eigenschaften und Probleme wie der Vanilla zu haben

BFS Patch

  • Aktuell für die Kernel 2.6.32 und 2.6.33 Verfügbar.
  • Erlaubt grundsätzlich das gleichzeitige Betreiben von Hl1 und Hl2 Servern auf einem System. Aber auch mit diesem Patchset gibt es eine geringfügige, zwar meßbare, hier aber im Spielfluss nicht zu merkende Beeinträchtigung
  • Erreicht ca 970 FPS mit PB 2
  • 1000 mit PB3 auch mit Spielern drauf
  • Mit PB3 und einer Tic von mehr als 1030 kommt es zu merkbaren Beschleunigungseffekten. Optimal hat sich ein Wert von 1001-1015 gezeigt.
  • Er wirkt minimal stabiler, wenn er auf einem 64 Bit System läuft.

>1000Hz

Eine Erhöhung des Kerneltimers auf mehr als 1000Hz bringt für Gameserver keine Vorteile. Wenn man mehr eine manuelle Änderungen der param.h macht, funktionieren viele Programme nicht mehr ordentlich. Nutzt man einen Patch hierfür ist dies zwar nicht der Fall, aber warum man ein instabileres System in Kauf nehmen sollte, obwohl man keinen Vorteil davon hat, lässt sich nicht weiter begründen.

Pingboost

Ob man Pinboost 3 wirklich braucht, bezweifle ich. Ohne den Spielern zu sagen, welche ticrate/pingboost eingestellt war, wurde kein Unterschied festgestellt. Es hieß, alle Server laufen gleich gut. Der Verbrauch ist bei Pingboost 3 wesentlich höher und so kann auch ein kleiner Gameserver ganz schnell die Leistung eines Kerns verbrauchen. Für einen Publichserver wird also Pingboost 2 oder keiner eure Wahl sein. Wenn ihr einen reinen Warserver haben wollt, dann könnt ihr über den Einsatz von Pingboost 3 nachdenken.

Vorbereiten des System

Ich gehe im folgenden davon aus, dass ihr wie viele Debian Stable 5.0 in 64bit benutzt.

Als erstes wird das System vorbereitet, und ein extra Benutzer für das Kernel Kompilieren angelegt. 

apt-get install kernel-package build-essential libncurses5-dev fakeroot

Wenn ihr nicht patchen und den Debain Kernel nur mit eigener Config neu backen wollt, braucht ihr noch die Sources: 

apt-get install linux-source-2.6.26

adduser kernel

Jetzt loggen wir und mit dem neuen User ein.

Sourcefiles

Für den BFS Patch laden wir die Sourefiles und den Patch runter, entpacken die Sourcefiles und spielen den Patch ein. 

wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.32.tar.bz2
wget http://ck.kolivas.org/patches/bfs/2.6.32-sched-bfs-316.patch
cd linux-2.6.32
cat ../2.6.32-sched-bfs-316.patch | patch -p1

Wenn ihr den Debian Kernel anpassen wollt, dann kopiert erst einmal die Sourcefiles des Debian Kernels in sein Homeverzeichnis und entpacken diese. 

cp /usr/src/linux-source-2.6.26.tar.bz2
tar xfvz linux-source-2.6.26.tar.bz2

Kernel Config

Als nächstes wechseln wir in das neu angelegte Verzeichnis mit den Sourcefiles und kopieren die Config vom aktuellen Kernel in das Verzeichnis. Achtet darauf, das ihr keine Kernelconfig von einem aktuelleren, als den zu kompilierenden nimmt. Hiermit sind bei mir schon Probleme aufgetreten. Am besten bootet ihr vorher den vorcompilierten Debian Standartkernel. Von alt zu neu geht nämlich ohne Probleme 

cd linux-2.6.32
cp -vi /boot/config-`uname -r` .config

Im Anschluss rufen wir menuconfig auf und editieren die Kernelconfig folgendermaßen. 

make menuconfig

Dies sind die wichtigsten Einstellungen:

  • General setup:
    • Local version - append to kernel release (Euren eigenen Kernelnamen in kleinen Buchstaben eintagen)
    • Einschalten: Automatically append version information to the version string
    • RCU Subsystem --->:
      • Ausschalten: Enable tracing for RCU (ignorieren, falls nicht vorhanden)
  • Processor type and features:
    • Ausschalten: Tickless System (Dynamic Ticks)
    • Einschalten: High Resolution Timer Support
    • Wähle deinen Prozessor unter Processor family
    • Ändere Preemtion Mode zu Complete Preemption (Real-Time)
    • Einschalten: Enable priority boosting of RCU read-side critical sections (ignorieren, falls nicht vorhanden)
    • Ausschalten: Enable tracing for RCU - currently stats in debugfs (ignorieren, falls nicht vorhanden)
    • Einschalten: Machine Check Exception and select Intel or AMD depending on your CPU
    • Ändere Timer frequency zu 1000 HZ
  • Power management options
    • Einschalten: Power Management support
      • Ausschalten: Power Management Debug Support
    • Ausschalten: Suspend to RAM and standby
    • Ausschalten: Hibernation (aka 'suspend to disk')
    • Einschalten: ACPI (Advanced Configuration and Power Interface) Support
    • Ausschalten: CPU Frequency scaling
    • Ausschalten: CPU idle PM support
  • Networking
    • Networking options
      • Einschalten: Packet socket: mmapped IO
      • Optional ausschalten: Network packet filtering framework (Netfilter) (Achtung! dies schaltet deine Firewall aus!)
      • Ausschalten: QoS and/or fair queueing (Außer du brauchst und benutzt es)
  • Device Drivers
    • Ausschalten: Watchdog Timer Support
    • Einschalten: Real Time Clock
      • Einschalten: PC-style 'CMOS'
  • Kernel hacking
    • Alles ausschalten

Compilieren

Wenn ihr damit fertig seit, sind wir bereit für das Kompilieren des Kernels: 

fakeroot make-kpkg clean && fakeroot make-kpkg kernel_image --initrd && cd ..

Holt euch eine Tasse Kaffee, das ganze dauert jetzt etwas. Wenn der Kernel fertig ist, erhaltet ihr ein .deb Packet, dass ihr mit dem root User installiert: 

dir
dpkg -i name.eures.eures.kernels.deb
update-grub

Neustart des Systems 

shutdown -r now

Nach dem Neustart solltest du prüfen, ob der neue Kernel auch läuft: 

uname -a

Es sollte sowas ähnliches ausgeben wie:
Linux euerHostname 2.6.32-euer-kernelname #1 SMP PREEMPT Sat May 8 13:30:53 CEST 2010 x86_64 GNU/Linux

Das wars

Ab hier macht man weiter, wie auch bei HL2 Servern: DE:Linux_Kernel_Optimierung#Die_Server_als_zeitkritische_Prozesse_eintragen

Beachtet dabei aber, dass der sirq-hrtimer durch den ksoftirqd zu ersetzen und der sirq-timer zu löschen ist.

Links

Retrieved from "http://wiki.fragaholics.de/index.php/DE:Linux_Kernel_Optimierung_HL1"