IP-Projects Gameserver Kernel

Dazu wäre interessant zu wissen was überhaupt geändert wurde

Das ist Firmengeheimnis ;) Nein, ich habe die Frage mal an den Techniker weitergegeben, der den Kernel gebaut hat. Sobald ich die Antwort habe, werde ich sie posten.
 
Kleine Anmerkungen zusätzlich - allein ein guter Kernel reicht nicht. Diese Angaben berufen sich auf teilweise etwas angestaubte Erfahrungen im Gaming-Bereich.

a) Priorität
Der/die Gameserver soll _IMMER_ vom System priorisiert werden - das ist schliesslich dessen Hauptaufgabe. Entsprechend sollte er auf höchster Priorität laufen - je nach Kernel ist das (preemptive) realtime.

b) Affinität
Um sicher zu stellen dass der CPU-interne Cache möglichst optimal genutzt wird und keine Prozesse die garantiert schnellen Zyklen des Gameservers unterbrechen sollten alle anderen Prozesse auf 1-2 Threads verteilt werden und jeder Gameserver an genau 1 CPU Thread gebunden werden. Zu beachten ist dass einige Gameserver(pluginS) Hintergrund-Threads betreiben, welche meist ohne Störungen auf den "System-Core" gebunden werden können um weder den Gameserver selbst noch andere Spieleserver zu stören.

c) Garantie
Um sicher zu stellen dass der Kernel auf keine dummen Ideen kommt wie das Interrupten der Gameserver (ja... das passiert sogar bei Realtime-Priorität) soll auf dem "System-Core" ein mit niedrigster Priorität (P=19) laufender "while(true) { }" C-Prozess laufen der vom System für alle Ticks oder Interrupts unterbrochen werden kann.

d) Anpassung
Schlafen ist so eine Sache... genau wie bei Menschen erwacht der Kernel-Wecker die Prozesse meist zu spät und es gibt Verspätungen. Es gibt dazu die Möglichkeit über LD_PRELOAD die entsprechenden Befehle (usleep/microsleep) an zu passen damit sie adaptiv auf Verspätungen reagieren. Dies ist aber schlicht meist nicht notwendig - hier sei es nur der Vollständigkeit halber erwähnt. Üblicherweise verwendeten die "1000fps" Hl/HL2-basierten Spieleserver diese Technik.
Man kann nach den im folgenden Link beschriebenen Methoden messen wie schnell und zuverlässig der Wecker klappt:
 
Snakoil lässt grüßen :eek:

Auf eigener Erfahrung weiß ich, dass die RT-Kernel reinster bullshit sind. Beim Spielen hatte ich nicht das Gefühl, dass mehr reingeht. Die Last ist angestiegen und weniger Slots waren auf Grund dessen möglich. Ich halte Gameserverkernel für Betrug. Gut, wenn die Kunden drauf stehen, dann sollen sie es bekommen. Der Schwachsinn hat seinen Höhepunkt erreicht, als 30.000 FPS-Kernel angeboten worden sind (Ja, gab es wirklich). Erreicht wurde das unter anderem mit einem Hack, der durch LD_PRELOAD um sleep durch eine andere Funktion (ich glaube usleep) und diversen anderen Schwachsinn ausgetauscht worden ist. Unter anderem hat Monk, der eigentlich selbst behauptet hat, dass FPS beim Server rein gar nichts bringen, seine Libs verkauft. Seit dem reagiere ich sehr empfindlich auf solche Angebote. Desweiteren ist es ohne Config des Kernels nicht möglich Patches einzuspilen, was für einen User, der auf Sicherheit achtet, nie in Frage kommen würde. Wahrscheinlich geistern immer noch irgendwelche Server im Netz herum, die uralte "gekaufte" Kernel einsetzen, bei denen Exploits möglich sind. Ich hoffe inständig, dass diese Provider gehackt werden und ihre Lektion daraus lernen!

Ich sage Finger weg von so einem Kernel, wenn keine Configs dabei sind!
 
Beim Spielen hatte ich nicht das Gefühl, dass mehr reingeht. /quote]
"Reingehen" ist ein äusserst subjektives Gefühl das zudem noch von dutzenden anderen technischen Faktoren abhängt so dass ein direkter Vergleich nicht möglich ist.
Rein technisch betrachtet verursacht preemptive RT ein bedeutend genaueres Aufwachen und kein Unterbrechen des Prozesses bei Kernelaufgaben was zu exakteren Ergebnissen und besseren Vorhersagen der Engine führt. Ob es wirkliche Auswirkungen hat sei dahingestellt - es soll ja auch Leute geben die ihre Spiele auf bedeutend höheren FPS-Zahlen spielen MÜSSEN als der Monitor überhaupt schafft.

Der Schwachsinn hat seinen Höhepunkt erreicht, als 30.000 FPS-Kernel angeboten worden sind (Ja, gab es wirklich).
Ja, ich hatte eine der ersten Libraries dazu geschrieben und veröffentlicht - war lustig zu sehen wie Clans schworen damit 1000x besser zu treffen =D
Es ist eigentlich ganz leicht zu bauen, allerdings ist es SEHR lustig die Fehler der Gameengine (zumal in Bezug auf Physik) zu sehen. Um so hohe Server-FPS stabil zu betreiben reicht übrigens kein Patch der usleep sondern man muss u.a. die gettimeofday() durch einen direkten Zähler der CPU-Ticks (Assembler-Befehl) emulieren. Rein von der Technik her eine sehr interessante Lernerfahrung wie man Prozesse und Systeme durch Manipulation der Libraries an ihre Grenzen schieben kann und die Präzision/Zuverlässigkeit von inherent non-RT Programmen stark erhöhen kann.

Unter anderem hat Monk, der eigentlich selbst behauptet hat, dass FPS beim Server rein gar nichts bringen, seine Libs verkauft.
Glaub mir - sein technisches Know-how war/ist auch keine Magie und meines Erachtens nicht umwerfend :D

Desweiteren ist es ohne Config des Kernels nicht möglich Patches einspielen, was für einen User, der auf Sicherheit achtet, nie in Frage kommen würde.
Echte Kernel-Patches sind gar nicht notwendig. Es gab damals schon sehr belustigende Feststellungen dass bspw der recht fette und keineswegs auf die notwendigen Kriterien abgestimmerter Ubuntu Standardkernel oft bessere Ergebnisse als die "magischen" Kernel der GS-Branche lieferten.

Snakoil lässt grüßen
Fakt ist dennoch dass auf einem technischen Niveau betrachtet es Optimierungspotential bei 0815-Kernel gibt. Ob es infolge von sehr stark varierende und oft rauschenden DSL-Leitungen aber überhaupt sinnvoll ist sei dahingestellt.
 
Du hast Recht. Das subjektive Gefühl ist kein Vergleich. Am einfachsten ist es, wenn man den GS einfach neustartet und nichts ändert, aber vorgibt er würde jetzt mit besseren Einstellungen laufen. Das bewirkt echt Wunder :-D

Bisher habe ich aber noch nie einen Vergleich gesehen (FPS des GS ist kein Vergleich), in denen zwei Kernel miteiander verglichen worden sind in dem man Messungen vorgenommen hat.

Zum Lernen und Verständnis der Engine sind die Libhacks sicherlich gut. Bisher habe ich nur einen vernünftigen Einsatz für so einen Libhack gesehen und der war um den GS beim erstellen von Dateien andere Dateiberechtigungen zu vergeben, als die von den Entwicklern erzwungenen.

Mit dem Patchen des Kernels meinte ich nicht die Optimierung, sondern die eigentliche Sicherheit. Wenn ich den Standardkernel der Distribution nehme, wird auch dieser aktualisiert wenn z.B. Bugs behoben worden sind, die Exploits ermöglichten. Sobald ich einen eigenen Kernel einsetze, muss ich diesen auch selbst patchen bzw. von der Quelle eine neue Version beziehen. Wenn die Config des Kernels nicht vorliegt, kann man ihn wohl kaum patchen. Falls doch, dann korrigiere mich. Soweit ich weiß haben alle, die ihren Kernel verkauft haben, genau diese Möglichkeit entfernt die Kernelconfig auszulesen. Ich meine es gibt zwei Möglichkeiten die aktuelle Config des Kernels zu bekommen. Eine Variante wäre über proc und die andere Variante sollte sich Kernelimage befinden, dass man mit einem Script auslesen kann.

Mich würde mal interessieren, wie viele Provider noch mit uralten Kernel unterwegs sind, bei denen Exploits bekannt sind.
 
Du hast Recht. Das subjektive Gefühl ist kein Vergleich. Am einfachsten ist es, wenn man den GS einfach neustartet und nichts ändert, aber vorgibt er würde jetzt mit besseren Einstellungen laufen. Das bewirkt echt Wunder :-D.
[OT/on]
Ich weiß noch von früher, wo wir einen Gameroot bei NGZ hatten. Das war ein Quadcore von Intel mit 8Gb Speicher. Auf dem liefen damals 7 Gameserver (cs:s) auf verschieden Ports. Dann haben wir 5 IP´s dazu bekommen und ich habe lediglich einige Gameserver auf die Standarports gesetzt, eine von den IP´s vergeben und neu gestartet. Erzählt habe ich natürlich ein Märchen, die Gameserver wären auf einen anderen Root gezogen usw. Und fast durch die Bank, alle Spieler aus dem Clan damals, sagten das der Gameserver jetzt viel besser läuft :confused: .
[OT/off]
 
:) Heißes Thema die Gameserverkernel. Im wesentlichen ist es ein Kernel, dessen HZ Zahl verändert wurde und bei dem einige kleine Schrauben gedreht wurden. Ich wollte hier keine Grundsatzdiskussion lostreten, lediglich ein kleines Spielzeug zum testen veröffentlichen für die etwas unbedarfteren Administratoren. Früher hätte ich mich gefreut, wenn ich so einen Kernel kostenlos bekommen hätte statt mich selbst Stundenlang mit den optimieren und anpassen eines Kernels auseinander zu setzen. Die Zeiten sind aber wohl vorbei, genauso die Zeit wo man 60 aktive Spielerslots auf einen Core2Quad Q9550 mit 8 GB RAM betrieben hat ;)
 
:) Heißes Thema die Gameserverkernel. Im wesentlichen ist es ein Kernel, dessen HZ Zahl verändert wurde und bei dem einige kleine Schrauben gedreht wurden.

Das hab ich zum Glück schon lange hinter mir gelassen. 10 Einstellungen verändern und das dann als Raketentechnik verkaufen. Am besten noch mit einem leet Suffix in der Kernelversion. Ich vertraue den Maintainern. Die wissen was sie tun und ich wäre zu faul den Kernel jedes mal zu patchen. Ich hoffe, dass ihr euer Angebot fortführt und auch sicherheitskritische Updates durchführt. Die Kernel zu releasen ist keine große Sache. Das Fortführen ist das Nervige daran.
 
Wir müssen unsere Kernel sowieso im zuge unserer auto installer warten. Der regelmäßige Release von neuen Versionen ist daher gegeben. Eventuell werden wir diese sogar in unsere Debian Mirror integrieren, damit man über apt-get update && upgrade bereits die neuen Kernelversionen einspielen kann.
 
Back
Top