Noga
Doppel-As
Dabei seit: 11.02.2007
Beiträge: 134
Dieser User hat sich mal bedankt
CPU: Intel Core Dou E6400
 |
|
 Die Wahrheit über:1000 FPS Gameserver |
     |
Also mal ganz sachlich gesehen ist es Bauernfängerei.....
A.) Die Theorie
Alle Ereignisse auf einem CS:S und CS 1.6 Server [1] werden pro Frame
berechnet. In einem Frame werden vor allem die Richtungen, Positionen und
Geschwindigkeiten eines Zeitpunktes zusammengefaßt. Der Frame ist also
gewissermaßen wie ein Schnappschuß aus einem laufenden Film (der deswegen
häufig auch „freeze frame“ heißt). Je mehr Frames pro Sekunde (FPS) berechnet
werden [2], desto genauer sind logischerweise dessen jeweilige Daten. Bei 1000
FPS berechnet der Server seine „Welt“ folglich mit einem Bild pro Millisekunde,
bei 100 FPS dagegen nur noch mit einem Bild pro 10 Millisekunden. Soweit ist
das Argument einer größeren Genauigkeit noch stimmig. Aber eben nur solange,
wie man nur den Server isoliert betrachtet, denn in der Praxis bleibt das ohne
ersichtlichen Nutzen.
B.) Die Praxis
Hier kommen die Spieler (Client) ins Spiel. Noch will ich aber beim Server
alleine bleiben. Der Server berechnet seine „Welt“ wie erwähnt in FPS. Bei 1000
FPS bleibt für einen Frame nur eine Millisekunde Zeit. Die Clients bekommen
aber nicht analog zu den Server FPS eine Information über alle Änderungen,
sondern viel seltener. Wie oft das pro Sekunde sein kann wird durch die Server
Tickrate bestimmt. Bei guten Servern ist diese auf 66 oder 100 eingestellt. Der
Server friert sozusagen pro Tick die „Welt“ des Spiels ein und merkt sich alle
wichtigen Daten. Danach entscheidet der Server, welchen Clients er diese Daten
(Updates) sendet. Dabei sendet der Server nicht die absoluten Positionen,
sondern nur die Veränderungen seit dem letzten Update. Die Tickrate bestimmt
also, wie häufig pro Zeiteinheit am Server aus den Frames sogenannte
„Snapshots“ gebildet werden, die an die Clients versendet werden. Ein Client
bekommt auf einem 100er Tickrate Server also höchstens 100 Updates pro Sekunde.
Das entspricht einem Update alle 10ms. Andererseits versorgt der Client den
Server ebenfalls mit seinen Eingaben (Commands). Auch hier bestimmt die
Tickrate des Servers, wie viele Commands er vom Client entgegennimmt. Und auch
hier wäre das bei einer Tickrate von 100 höchstens ein Command alle 10ms.
Und genau hier fällt das Kartenhaus in sich zusammen. Mit was soll denn der
Server jede Millisekunde rechnen, wenn er nur alle 10 Millisekunden einen Wert
von den Clients erhält? Dem Server bleibt ja nichts anderes übrig, als 90%
seiner Rechenzeit mit veralteten Daten zu arbeiten. Nimmt man jetzt noch den
Umstand hinzu, dass die Clients alle mit unterschiedlichen Latenzen ihre
Commands senden und diese auch erst noch in Warteschlangen auf dem Server
zwischengespeichert werden, so wird schnell klar, dass 500, 600 oder gar 1000
FPS eigentlich völliger Unsinn sind. Der Server muss in der Regel mit Daten
arbeiten, die 50ms und älter sind. In dieser Zeit haben die Clients schon
wieder unzählige Richtungsänderungen vorgenommen und Tasten gedrückt. Der
Server muss also eine Vorhersage machen (prediction), man könnte auch sagen er
muss „raten“, was die Spieler als Nächstes machen werden. Er berechnet also
mitunter eine ganz andere Bewegung als die, die der Spieler tatsächlich macht,
bei 1000 FPS dann halt auf die Millisekunde genau. Es macht aber keinen
Unterschied, ob der Server nun mit 333 FPS läuft oder mit 1000 FPS. Ein
falsches Ergebnis bleibt in beiden Fällen falsch. Bei 1000 FPS ist es nur
„genauer falsch“.
Der nächste Einwand lässt nicht lange auf sich warten: "Ja, aber wenn der
Server richtig liegt?" Stimmt. Hat der Server richtig geraten, dann ist die
Position eines Gegners tatsächlich genauer. Auf dem Server! Nicht aber auf dem
Client! Die Engines von CS:S und CS 1.6 gehen davon aus, dass die Zeit am
Server und am Client synchron ist. Die Zeit des Servers ist bindend für alle
Clients. Der Server speichert dazu pro Frame die sogenannte Frametime. Das ist
bei guten Linux Servern auf die Millisekunde genau. Der Client betrachtet nun
die Frametime, die mit jedem Update übertragen wird, als seine eigene Zeit. Auf
einem Server mit 1000 FPS und 100er Tickrate erhält der Client also im
günstigsten Fall immer ein Update, in dem die Frametime 10ms weitergelaufen
ist. Diese Vorgehensweise wird auch deshalb benötigt, weil unter Windows der
Timertick sehr ungenau ist. Aber auch hier ist ein 1000 FPS Server nicht
genauer. Möglicherweise hat er die Bewegungsrichtung eines Spielers richtig
erraten (predicted), aber es reichen schon 1-2ms Schwankung in der
Paketlaufzeit vom Server zum Client, um das Ergebnis wieder so ungenau zu
machen, dass es keinen Unterschied zwischen 333 und 1000 FPS gibt. Und in aller
Regel sind die Latenzunterschiede noch weit größer.
Das bringt uns zum nächsten Einwand und gleichzeitig zu einem weit verbreiteten
Irrtum: „Der Server berechnet doch die Latenz mit." Richtig. Der Server
berücksichtigt auch die Latenzen der Spieler. Um diese richtig zu berechnen,
benötigt er aber erst mal ein Commandpaket vom Client. Dieser Wert wird über
mehrere Pakete gemittelt und in die Berechnungen des Servers mit einbezogen.
Schon das Mitteln des Wertes führt zu einer Ungenauigkeit. Und viel wichtiger:
Es betrachtet nur die Vergangenheit und nicht den in diesem Moment
tatsächlichen Wert. Somit ist auch hier kein Unterschied zwischen 333 und 1000
FPS gegeben. Es herrscht auch der weit verbreitete Irrtum, dass man mit den
Werten cl_cmdrate 100, cl_updaterate 100 und rate 30000 genau das vom Server
bekommt. Das ist schlicht falsch. Sowohl in CS:S als auch in CS 1.6 ist der
Server autoritativ. Das heißt, der Server entscheidet unter allen Umständen,
wann und was er dem Client sendet und was er vom Client empfängt und
verarbeitet. Der Client wünscht sich allenfalls 100 Updates pro Sekunde. Der
Server kann aber auch nur 90 senden.
Auch hier sind die 1000 FPS eher kontraproduktiv. Ist der Server unter hoher
Last und kann die 1000 FPS gar nicht mehr berechnen, dann entscheidet er sich
oft dafür, den Clients weniger Updates zu senden und weniger Eingaben
(Commands) zu verarbeiten um seine maximale FPS Rate zu erreichen, denn diese
wird von der Engine mit höherer Priorität betrachtet als die Updates und
Commands. Das ist wichtig, weil insbesondere die Source Engine aber auch CS 1.6
alle Berechnungen pro Frame machen. Kein Frame, keine Berechnungen, keine
Updates. Die Engine wird unter allen Umständen versuchen, die am Server
eingestellten FPS zu erreichen. Dabei werden die Eingaben der Clients schlicht
verworfen. Das macht einen Server, der konstant mit 333 FPS läuft, dann sogar
um einiges genauer als einen Server, der ständig zwischen 500 und 1000 FPS
schwankt, was derzeit eher die Regel als die Ausnahme bei vielen auf 1000 FPS
aufgebohrten Servern darstellt.
Fazit: Es ist nicht wichtig, ob ein Server mit 333, 500, 600 oder gar 1000 FPS
läuft. All diese Werte machen einen CS:S /Cs 1.6 Server genau genug. Viel wichtiger
ist, dass der Server gut angebunden ist und die eingestellten FPS möglichst
immer erreicht. Für genauere Positionen und eine bessere Hitregistration kann
nur Valve Software selbst sorgen, indem die Berechnungen für Prediction,
Extrapolation und Interpolation möglichst robust und genau sind.
[1] Das Folgende bezieht sich auf die Source TM Engine von Valve Software und
CS:S. Man kann es im wesentlichen aber auch auf CS 1.6 anwenden.
[2] Inwieweit man bei einem Server überhaupt von FPS sprechen kann ist
umstritten. Einerseits rendert der Server nicht wirklich ein Bild, andererseits
ist durch die Architektur der Engine alles auf diese Frames per Second oder
Bilder pro Sekunde ausgelegt.
Quelle & text dazu:
Dieser Link wird erst nach der Registrierung angezeigt.
tja nun dürfen mal die pros dran, was halt ihr davon?
__________________
Dieser Link wird erst nach der Registrierung angezeigt.
|
|
vbdesigns.de 
