1000 fps ...
I wonder why this fairy tail is still alive.
With a max update rate of 100 you send the server informations for 100 frames, not 1000!
That means that your server calkulates 900 frames for NOTHING as it uses the same data you semdwith the last cmd_update. Even if you say you have 32 clients on your server and everone could send his data at a different frame you would only need 320 frames . So even then your server spends more than 60% of his CPU to create a warm server room. Having a constant fps is much more important than a high one. Because the first thing a server does when not reaching the set fps is to drop data. This results in loss and choke.
So if you want to do sokething good for your server set max fps to 200, not more and then set the rates to your needs
Oh man so much misinformation in this though. Wow..
100 fps = 10 ms delay
200 fps = 5 ms delay
1000 fps = 1 ms delay
Do the maths.. also all of the server communication is async, so the "you only need 320 frames" is such bs, you can't calculate like this. Only thing that I agree with you is that it's preferrable for it to be constant.
And the difference between playing with a ping of 20 to 30 is what? Not noticeable.
EDIT: I found this artice a while ago that describes the dependencies between the server and the client. Sadly in german, try to google it.
Spoiler
Quote:
In letzter Zeit liest man bei einigen Serveranbietern und in den Foren diverser
CS:S Ligen von angeblich ganz tollen Servern, die mit 1000 FPS laufen sollen.
Mit diesen 1000 FPS soll der Server noch besser laufen und alles viel genauer
berechnen als mit den Standardeinstellungen. Der Spieler soll vermeintlich
besser treffen, die Positionsberechnungen des Server sollen genauer sein und
als "competitive player" braucht man einen solchen Server natürlich sowieso.
Die bei den diversen Anbietern zu findenden Angebote sind, soweit sie sich auf
diese Server FPS beziehen, recht ungenau und verwirrend. Teilweise wird da der
Eindruck erweckt, die Server seien in irgendeiner Form "FPS zertifiziert", ohne
auch nur zu erwähnen, was denn das für eine Zertifizierung sein soll. Man kann
davon ausgehen, dass man das seitens der Anbieter selbst erfunden hat oder
anders ausgedrückt die Zertifizierung in Wirklichkeit eine subjektive Meinung
darstellt. Sind diese Server, die mit 1000 FPS statt "nur" mit 333 oder 500 FPS
laufen, denn nun wirklich genauer? Nein! Können sie auch gar nicht. Aber warum
nicht?
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 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.
Also: lasst Euch nicht von dem Prädikat 1000 FPS in die Irre führen oder dazu
drängen, in Wars nur auf solchen Servern zu spielen, denn es ist reines
Marketing-Geklingel. Nicht mehr und nicht weniger.
---
[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.
When I use HLSM to run HLDS In Service mode, it says Fatal Error : unable to initilize steam, but when I run it with HLSM without the service mode it works perfectly.
And the difference between playing with a ping of 20 to 30 is what? Not noticeable.
EDIT: I found this artice a while ago that describes the dependencies between the server and the client. Sadly in german, try to google it.
10 ms is huge actually. Some internet providers pay sometimes k$ to get reduced latencyy by even 2 ms, for Forex trading for example.
In an ideal world, yes it doesn't matter. But in the real world, you are not even considering retransmit issues, jitter, etc. Having a 10 ms difference can change into 20 ms and 30 ms. You are basically raising your average latency by 10 ms, imo, that's huge.
tl;dr: 1000 FPS are useless because the clients are unable to send information to the Server that fast that the server could use them
Makes no sense. It's not about how fast the client sends, it's about how fast the server proceeds the requests.
Visibly you're above your head in this comment. Anyways..
10 ms is huge actually. Some internet providers pay sometimes k$ to get reduced latencyy by even 2 ms, for Forex trading for example.
In an ideal world, yes it doesn't matter. But in the real world, you are not even considering retransmit issues, jitter, etc. Having a 10 ms difference can change into 20 ms and 30 ms. You are basically raising your average latency by 10 ms, imo, that's huge.
You cannot compare a gameserver with billion dollar trades, that argument does not count.
Quote:
Originally Posted by Misery
Makes no sense. It's not about how fast the client sends, it's about how fast the server proceeds the requests.
Visibly you're above your head in this comment. Anyways..
And here again: you cannot watch the server allone. In a perfect world you could, but this is all other than a perfect world.
All it does with the 1000 fps is it sounds good, good enough for providers to get your money.
EDIT: When I use HLSM to run HLDS In Service mode, it says Fatal Error : unable to initilize steam, but when I run it with HLSM without the service mode it works perfectly.
And By the way Modrdekay, I've got two answers, one from Kia and the other is from Bacardi, Kia's rates are low and Bacardi rates are high.
I never told you a single rate, so i don't know why you point on me about that.
However your other question sounds like a problem with HLSM to me as it seems to be not 100% compatible with hlds.
You should post your question to the creator of HLSM
Linear Mode
