@michael-08:
Ach wie suess. LMGTFY hatte ich ja schon fast vergessen. Danke uebirgens fuer die Erinnerung dass ich die 'Preview'-Funktion bei Tinyurl noch aktiv habe...
Das Wort "Update" impliziert nicht Neuheit sondern eine Auffrischung, ein Auf-den-Tagesstand-bringen. Demnach ist es weiterhin die "alte" (und gleichzeitig "neue") bekannte SourceEngine...
Ich habe mit meinen 52 Slot Tick 100 5.8 Megabyte pro Sekunde (in/out)verbraucht! Bei 300 Slot 100 Tick wären das ~24 Megabyte/sekunde
Laut deiner Berechnung vom "14.06.2010 17:09" belegt jeder Spieler 25 kB/s.
Laut dieser Berechnung belegen sie 111 kB/s. Was denn nun
Die benoetigte Bandbreite variiert je nach Anzahl der uebermittelten Deltas (Interaktionen mit der Spielwelt). Je mehr Spieler in einer World sind, desto mehr Interaktionen mit der Spielwelt und zwischen den Spielern gibt es, desto groesser die Deltas zwischen den vorherigen Frames der Clients und dem neuen des Servers. Mit 32 stillen Spielern ist die Bandbreite viel niedriger als mit 6 Berserkern, somit kann man die Bandbreite nicht pauschal vorhersagen. Kleine Randnotiz: die "Lags" am Rundenbeginn resultieren aus dem Fakt dass der Delta groesser ist als die Paketgroesse und somit in mehreren Paketen uebermittelt werden muss - die Zeit bis der Client ein neues Paket hat erhoeht sich und somit auch exponentiell die Gefahr dass seine eigenen Vorhersagen falsch sind und revidiert werden muessen - es "laggt".
Dazu kommt noch der Fastdownload
Einen Webserver - und zumals einen solchen wie die Standartkonfiguration des Apaches in den gaengigen Distributionen - sollte man nicht auf einen Gameserver packen. Der Grund ist dass Webserver unter Belastung die CPU erst bei Aufforderung durch den Kernel wieder freigeben und somit wertvolle zusammenhaengende Zyklen belegen was den Jitter der nanosleep()-Funktion des Gameservers herumspringen laesst.
Mehr Server FPS = mehr Berechnung, somit genauere Ergebnisse! Fakt!
Du kennst sicherlich den Winston Churchill zugeschriebenen Ausdruck "Traue keiner Statistik, die du nicht selbst gefälscht hast".
Du solltest mit geeigneter Hardware und ausreichend Zeit zum gleichen Resultat kommen wie ich vor knapp einem Jahr nachdem ich ueber eine Woche lang damit herum experimentierte.
Als kleinen Anfangs"beweis" soll folgender Versuch gelten: bau eine Preload-Klasse die usleep() durch einen eigenen direkten Aufruf der nanosleep()-Funktion ersetzen geht (bitte den Faktor 10^3 zwischen Mikro- und Nanosekunden nicht vergessen). Dann misst du simpel die Zeit zwischen 2 Aufrufen der usleep()-Funktion und schreibst dies in eine Shared-Memory. In der Annahme dass der Server konstant 1000FPS faehrt und auf Tick100 konfiguriert ist wirst du eine frappierende Erkenntnis sehen: (je Sekunde)
- 900 Frames haben (fast) ohne Verzoegerung direkt usleep() wieder aufgerufen
- 100 Frames haben eine geringe Zeit benoetigt.
Die 100 Frames sind die Tick-Frames in welchen die Welt neu berechnet wird und Deltas zu den vorherigen produziert werden.
Die anderen 900 Frames sind socket-call's wo der Gameserver seine Listener abprueft ob ein Client ein Paket geschickt hat (neue Client-Daten) und ob er den Clients (je nach konfigurierter cl_updaterate und rate) neue Pakete schicken darf. Hoehere FPS bedeutet dass der Gameserver die Pakete genauer ausliefert aber der Inhalt ist immer gleich alt.
CPU-Probleme kriegt ein Gameserver sobald die Berechnung eines World-Updates laenger dauert als die Zeit zwischen 2 Tick's; die Ticks verschieben sich und Updates kommen seltener. Laut fragaholics (ungeprueft) betraegt der Unterschied zwischen 100 und 500 FPS 5ms schnellere RTT, zwischen 500 und 1000 nur noch 1ms. (Exponentielle Kurve!) Die RTT-Variationen im Providernetz sind also ausschlaggebender als der Gameserver. CQFD
(Nicht applizierbar auf -pingboost3 der GoldSRC-Engine)
@IP-Projects:
Spaetestens wenn der Server mal voll waere wuerde er es nicht lange bleiben
Aber bei Gameserver kann man die Mischkalkulation (zumindest als Clan) gut hinnehmen - ein Root auf welchem alle Slots ausgereizt waren hatte ich bis jetzt noch nicht zu sehen bekommen
