| MTU-Wert:
Vor- und Nachteile von MTU
IP Header Komprimierung
MTU Auto Discovery
Router und MTU
RWIN-Wert
Vor- und Nachteile von RWIN
Optimierung (Downloads)
Optimierung (Games)
Low RWIN - Einleitung CS 1.6 & CS:SOURCE;
Low RWIN - Erklärung CS 1.6 & CS:SOURCE;
Kompression
Welche Kompressionsarten gibt es?
IP Header Compression
Softwarekomprimierung
Was ist Loss? Was ist Choke?
Loss und Choke CS 1.6 & CS:SOURCE
Erklärung: Loss
Erklärung: Was Choke NICHT ist
Erklärung: Choke
Ping
Bandbreiten & Pings
Der Scoreboard-Ping CS 1.6 & CS:SOURCE;
Der Netgraph-Ping
Welcher Ping ist wichtig?
Tickrate
Was ist die Tickrate?
Zwei verschiedene Tickrates:
Hohe oder niedrige Tickrate?
Netsettings
Netzbezogene Consolenbefehle CS 1.6 & CS:SOURCE
Was ist wichtig? CS 1.6 & CS:SOURCE
Empfehlungen
Empfehlungen CS 1.6
Hinweis: Einzelschuss CS 1.6
Empfehlungen CS:SOURCE
Interpolation CS:SOURCE
Vor- und Nachteile von MTU
Versandte und empfangene Datenpakete haben höchstens eine maximale Größe, die durch den MTU-Wert angegeben wird, was natürlich mit der Menge der jeweils übertragenen Daten mal mehr, mal weniger nah am Maximum liegen kann - daher die Sinn machende Bezeichnung \"Maximum Transfer Unit\". Da nun jedes Datenpaket, unabhängig von der Menge an verwertbaren Daten, an (nicht verwertbaren) Headerdaten, sofern diese nicht komprimiert werden, immer 40 zusätzliche Byte enthält, wird mehr Bandbreite für die gleiche zu übertragende Datenmenge benötigt, je größer die Anzahl kleiner, zu übertragender Datenpakete wird. Man spart also an unverwertbaren Headerdaten, je größer die verwendeten Datenpakete sind - daher hat man, je näher der MTU-Wert an der Obergrenze liegt, oberhalb welcher die Datenpakete fragmentiert, d.h. in mehrere Pakete aufgeteilt werden, immer bessere Datendurchsatzraten bei Up- und Downloads. Ein bei Up- und Downloads nicht relevanter Nachteil dieser Optimierung ist, dass jedes Datenpaket bei seinem Ziel erst vollständig ankommen muss, bevor der jeweilige Rechner damit irgendetwas machen kann. Bei Onlinespielen ist dieser Effekt hingegen spürbar.
IP Header Komprimierung
Es existiert eine Header-Komprimierung, welche die Headerdaten bei jedem Datenpaket vermindern kann. Im Durchschnitt spart man dadurch 90% an Headerdaten, da diese nur noch ca. 3-5 Byte groß sind. Weitere Informationen dazu sind im Bereich Kompressionsarten zu finden
MTU Auto Discovery
Das so genannte MTU Auto Discovery sorgt dafür, dass beim Aufbau einer Verbindung ein an der Obergrenze befindlicher MTU-Wert vereinbart wird, unabhängig von dem MTU-Wert, welchen man selbst eventuell vorher festgelegt hat. Die Auto Discovery Funktion ist also für Downloads sehr sinnvoll, für Onlinespiele hingegen weniger.
Router und MTU
Die unter \"Vor- und Nachteile von MTU\" zu findenden Informationen über den MTU-Wert und dessen Bedeutung sind, sofern ein Hub, ein Switch, ein Router oder ein Router-Rechner zwischen dem eigentlichen Spielerrechner und dem Internetanschluss hängt, noch erweiterungsbedürftig. In solch einem Fall nämlich muss die MTU-Variable auf jeder \'Station\', die dies unterstützt, zusätzlich auf den gewünschten Wert geändert werden - andernfalls hat die Änderung auf dem Spielerrechner keinen Einfluss.
Vor- und Nachteile von RWIN
Das TCP-Protokoll baut auf hoher Verlässlichkeit auf - so erwartet beispielsweise ein im Internet befindlicher Server, welcher an jemanden Daten verschickt, dass dieser die angekommenen Daten regelmäßig bestätigt. Nun wäre es nicht sonderlich effizient, würde man jedes eingetroffene Datenpaket einzeln bestätigen, was eine enorme Menge an Bandbreite kosten würde, so dass vor Beginn eines Datentransfers immer erst ein Empfangs-Fenster (Receive Window) vereinbart wird. Der Sender schickt dann eine bestimmte Menge an Daten und wartet auf die Empfangsbestätigung - ist diese eingetroffen, folgt ein weiterer Schub an Daten. Je kleiner das Receive Window ist, desto besser kann erkannt werden, wann Packetloss (Verlust von Datenpaketen) auftritt - wenn beispielsweise 2000 Byte Receive Window vereinbart sind und es kommen nur 1993 Byte an, dann wird der Datensender keine Empfangsbestätigung erhalten und die Daten in Folge dessen erneut senden, bis sie vollständig angekommen sind und der Empfänger den vollständigen Empfang bestätigt hat. Je größer nun das Receive Window ist, desto seltener muss der Empfänger Bestätigungen versenden - der Nachteil liegt hierbei jedoch bei Verbindungen, die Packetloss haben: denn wenn beispielsweise 32KB an Daten neun-mal nur unvollständig ankommen und erst beim zehnten mal vollständig sind, wären ganze 320KB an Daten verschickt worden, obwohl eigentlich nur ein einziges 32KB-Datenfenster vollständig angekommen ist. Man verursacht bei Packetloss und hohem RWIN-Wert also unnötige Datentransfermengen - mehr Datentransfer und mehr Übertragungsfehler, je größer der RWIN-Wert gewählt ist.
Optimierung (Downloads)
Zum Einstellen der windowsseitigen Optimierungen - andere als diese sind für Downloads nicht nötig - eignen sich diverse Programme, welche die entsprechenden Einträge in der Windows-Registry ändern. Nun gibt es viele verschiedene Treiber und Zugangsmöglichkeiten, welche alle auf verschiedene Einträge in der Registry zurückgreifen, weshalb ein Großteil der Programme dieser Art nicht zu gebrauchen ist, da manche nur die Registryeinträge einiger weniger Zugangsmöglichkeiten anpassen und somit bei allen anderen Treibern und Zugangsmöglichkeiten keinerlei Wirkung zeigen. Ein Programm, das zu den zuverlässigsten zählt, nennt sich BeFaster, da es jeden Wert mehrfach in die Registry schreibt, so dass praktisch alle bekannten Zugangsmöglichkeiten dadurch abgedeckt werden. Viele Einstellungen, auf welche man sonst überhaupt keinen Zugriff hat, kann man darüber ändern und optimieren.
Um Downloads zu beschleunigen, ist es nötig, den prozentualen Anteil nicht verwertbarer Daten so weit wie möglich zu minimieren. Da jedes Datenpaket, sofern die Header-Komprimierung nicht aktiviert ist, immer 40 Byte nicht verwertbare Headerdaten enthält, sollten die Datenpakete so groß wie nur möglich sein, wodurch der prozentuale Anteil der Headerdaten immer weiter sinkt, also immer mehr Prozent der verwendeten Bandbreite für die tatsächlich zu transferierenden Daten zur Verfügung stehen. Beispielsweise sind 40 Byte von 1492 Byte weniger als 3%, wohingegen 40 von 300 Byte bereits über 13% ausmachen, also mehr als 13% nicht verwendbare Bandbreite, wenn man die Internetanbindung voll auslasten will. Wenn Sie BeFaster installiert haben, ändern Sie nichts in den Anfängereinstellungen, lassen also die drei Spieleoptimierungen deaktiviert, da diese ansonsten die Einstellungen für Fortgeschrittene, welche Sie noch einstellen werden, beeinflussen und teils umkehren würden. Wählen Sie also die Einstellungen für Fortgeschrittene aus, suchen dort den so genannten MTU-Wert, wählen Sie in dem Pulldown-Menu \"Eigene...\" aus und tippen anschließend im rechts daneben befindlichen Textfeld einen Wert zwischen etwa 1440 und 1492 ein. Sie fragen sich nun eventuell, warum einzelne Datenpakete nur etwas größer als 1 KB sind und warum man nicht einfach einen sehr viel größeren Wert einsetzen sollte - das hängt damit zusammen, dass oberhalb einer gewissen Höchstrenze ein Datenpaket in mehrere aufgeteilt wird, wobei jedes zusätzliche Datenpaket jeweils weitere 40 Byte unverwertbare Headerdaten enthält. Diese Höchstgrenze befindet sich in eben diesem Bereich - um die Grenze genau zu ermitteln, stellen Sie einen Wert ein, rebooten den Rechner, stellen die Internetverbindung her und pingen dann (über ein entsprechendes Programm oder über den MS-DOS-Befehl \"ping\") die Website Ihres Providers an. Über die MS-DOS-Eingabeaufforderung bewerkstelligen Sie dies, indem Sie, wenn Ihr Provider beispielsweise T-Online ist, einfach \"ping t-online.de\" eingeben. Sie werden von dem Ping-Befehl darauf hingewiesen, wenn die Daten fragmentiert, also in mehrere Teile aufgeteilt werden mussten. In diesem Fall senken Sie solange den gewählten MTU-Wert und versuchen es erneut, bis der Ping-Befehl keine Datenfragmentierungen mehr meldet.
Ein weiterer wichtiger Wert, welcher nicht verwertbare Daten senken kann, nennt sich RWIN (Default Receive Window), welcher in dem Programm BeFaster unter derselben Karteikarte wie der MTU-Wert gefunden werden kann und dort \"RcvWindow\" genannt wird. Dieser Wert gibt an, nach einer wie großen Datenmenge der Empfänger dieser Daten eine Empfangsbestätigung an den Versender dieser Daten abschicken muss, bevor der nächste Stoß an Daten versendet wird. Je niedriger der RWIN-Wert gewählt ist, desto öfter geschieht dies und desto mehr Bandbreite opfert man gewissermaßen freiwillig. Man sollte einen Wert wählen, der ein Vielfaches von MTU-40 (auch MSS genannt) ist, da RWIN lediglich die verwertbaren Daten \"mitzählt\", die Headerdaten von jedem Datenpaket also ignoriert, und idealerweise nur nach vollständig angekommenen Datenpaketen Empfangsbestätigungen versenden sollte.
Haben Sie diese Einstellungen über BeFaster vorgenommen, klicken Sie links unten in BeFaster auf den Button zum Übernehmen der Optimierungen und führen anschließend einen Reboot durch - schon können sich an erhöhten Übertragungsraten erfreuen. :-)
Optimierung (Games)
In Multiplayerspielen dreht es sich nicht selten darum, gute Reaktionen in kritischen Situationen vorweisen zu können. Führen wir an dieser Stelle ein kleines Gedankenexperiment durch: stellen wir uns vor, Sie spielen Ihr Lieblings-Multiplayerspiel und befinden sich gerade in einer Situation, die es erfordert, so schnell wie möglich zu reagieren. Das Spiel sendet rund 4000 Byte pro Sekunde an den Server und Sie haben in Windows einen MTU-Wert von 1440 eingestellt, welcher für Downloads nahezu optimal wäre. Durch den MTU-Wert werden die vom Spiel jede Sekunde übertragenen Daten in nahezu drei Pakete pro Sekunde aufgeteilt - jedes davon wird erst einmal vollständig zum Gameserver übertragen. Sobald es dort vollständig angekommen ist, bemüht sich der Server dann auch, es zu verarbeiten. Wenn Sie nun eine reaktionskritische Situation im Spiel vor sich haben und schnell handeln müssen, während gerade ein neues Datenpaket begonnen hat, haben Sie durch die Aufteilung aller Daten in drei Pakete pro Sekunde im Extremfall eine Verzögerung von einer Drittelsekunde, also vergleichbar mit einem Ping von über 300 (!) Millisekunden. Was also kann man tun, damit die Sekunde im Spiel nicht nur aus drei Teilen (d.h. aus drei Datenpaketen) besteht? Wir müssen den MTU-Wert senken - je weiter wir diesen Wert senken, desto mehr Teile hat eine Sekunde und desto schneller können Ihre kritischen Reaktionszeiten auch vom Server erfasst und verarbeitet werden, da sie einfach früher dort vollständig ankommen.
Es gibt durch eine zu drastische Senkung des MTU-Wertes jedoch einige Nachteile, die unterhalb gewisser Grenzen beginnen:
- Manche Websites können nicht mehr aufgerufen werden
- Das Auflösen von Domains auf IP-Adressen dauert länger
- Die Gesamtmenge der Daten enthält prozentual mehr nicht verwertbare Daten, darunter Headerdaten
Um letzterem entgegenzuwirken, existiert neben MTU ein weiterer, relevanter Wert namens RWIN (Default Receive Window) - in BeFaster finden Sie diesen in derselben Karteikarte, in welcher sich auch MTU befindet, und zwar unter der Bezeichnung \"RcvWindow\". Diesen sollten Sie auf einen hohen Wert stellen, welcher grundsätzlich ein Vielfaches von MTU-40 sein sollte. Ein hoher RWIN-Wert dient dem Zweck, dass Ihr Rechner, wenn er Daten empfängt, eine bestimmte Menge an Daten abwartet, bevor er eine Empfangsbestätigung abschickt. Diese Empfangsbestätigung wiederrum erwartet der Sender der Daten, bevor er weitere Daten an Ihren Rechner abschickt. Wäre für RWIN nun sehr niedrig gewählt, so dass beispielsweise nach jeweils 50 Byte eine Empfangsbestätigung verlangt wird, würde dies aufgrund der Übertragungsdauer von Daten und Empfangsbestätigungen die Bandbreite stark einschränken. Ein Internetanschluss, über welchen man einen Ping von 100ms hat, würde dann folgendes Szenario liefern, wenn man beispielsweise eine Datei herunterlädt: Nach den ersten 50 Byte wird die erste Empfangsbestätigung abgeschickt, welche eine Zehntelsekunde (100ms) benötigt, um zum Sender der Daten zu gelangen. Dieser sendet dann erneut 50 Byte Daten, welche ihrerseits wiederrum eine Zehntelsekunde benötigen, bis sie bei Ihrem Rechner eintreffen, welcher diese wieder mit einer Empfangsbestätigung bestätigt, die erneut 200ms Zeit benötigt, bis sie beim Server eingetroffen ist. Grob geschätzt, hätte man dadurch - selbst wenn die Anbindung eine 100Mbit-Standleitung wäre - eine Datendurchsatzrate von gerade einmal 250 Byte pro Sekunde. Diese Situation ist also der Extremfall eines zu niedrig gewählten RWIN-Wertes und sollte verständlicherweise vermieden werden.
Empfehlenswert ist dabei ein Wert, der in etwa dem Doppelten Ihrer Upstream-Geschwindigkeit (Versandgeschwindigkeit, z.B. 128Kbit / 8 = 16KByte/s bei T-DSL) entspricht, so dass also nur alle zwei Sekunden eine Empfangsbestätigung abgeschickt wird. Dies ist natürlich keinerlei Pflichtwert - Sie können eben so gut auch einen anderen Wert wählen, wobei ein noch höherer Wert prinzipiell nur dann einen Vorteil bietet, wenn man zum Beispiel Dateien von einem Server herunterlädt, zu welchem man eine extrem hohe Pingzeit von mehreren Sekunden hat. Verwenden Sie, wenn Ihre Internetanbindung 16KB/s (= 16384 Byte pro Sekunde) Upstream hat, bei einem MTU-Wert von 250 einen RWIN-Wert von (250-40)*156 = 32760, wobei Sie für 156 selbstverständlich auch einen anderen Faktor einsetzen können. Es spielt dabei keine objektiv wichtige Rolle, ob dieser Faktor durch bestimmte Zahlen teilbar oder ob er ein Vielfaches irgendeiner Zahl ist. In diesem Beispiel wird darauf geachtet, dass der RWIN-Wert in etwa dem Doppelten der Upstream-Bandbreite entspricht, was, wie oben erwähnt, jedoch absolut kein Muss ist. Er kann prinzipiell auch relativ zum verfügbaren Downstream gewählt werden. Dabei sollte darauf geachtet werden, dass bei erhöhten Pings die maximale Downloadrate durch RWIN auf gewisse Grenzen eingeschränkt werden, was über den Analyzer von Speedguide praktisch abgelesen werden kann. Die MTU-bezogenen Hinweise des Analyzers sind nur auf höchste Downloadraten bezogen und können daher in Bezug auf Onlinegaming-Optimierungen ignoriert werden.
Haben Sie die beiden hier genannten Optimierungen durchgeführt, rebooten Sie bitte Ihren Rechner. Anschließend sollten Sie noch für Ihr(e) Multiplayerspiel(e) die spiel-eigenen Netzwerkeinstellungen optimieren.
Low RWIN - Einleitung CS 1.6 & CS:SOURCE;
Seitdem die Abkürzungen MTU und RWIN vielen CS-Spielern etwas sagen, hört man auch desöfteren etwas über ein Phänomen class=\"ueber\" namens \"Low RWIN\". Doch was ist das und was hat es damit auf sich? Low RWIN heißt, dass der RWIN-Wert (TCP Receive Window) auf dem eigenen Rechner sehr niedrig eingestellt wird, wodurch das Spielgefühl in CS sowohl besser als auch schlechter wird: einerseits kommen auf viel mehr Servern die Schüsse dort an, wo sie ankommen sollten, während das Spielgefühl gleichzeitig sehr ruckartig wird.
Low RWIN - Erklärung CS 1.6 & CS:SOURCE;
Mit dem RWIN-Wert ist die Aufgabe verknüpft, dass Daten, die über das TCP-Protokoll (also im Internet oder auf LAN) versendet werden, sicher ankommen sollen. Dies wird realisiert, indem eine bestimmte Datenmenge durch eine Empfangsbestätigung abgesichert wird. RWIN bestimmt nun, welche Menge an Daten versendet wird, bevor eine Empfangsbestätigung abgewartet wird. Ist die Empfangsbestätigung eingetroffen, wird der nächste Stoß an Daten geschickt. Empfangsbestätigung. Datenstoß. Und so weiter. Nun benötigt jede Empfangsbestätigung eine gewisse Zeit, bis sie ankommt - in der Zeit werden keine Daten versendet. Je öfter also Empfangsbestätigungen abgewartet werden, desto mehr Zeit vergeht durch das Warten auf jene Bestätigung und desto mehr sinkt aus diesem Grund die durchschnittliche Datenübertragungsrate.
Diese Pausen sorgen in CS dafür, dass die Datenübertragung ausgebremst wird - so als würde man in CS cl_cmdrate absenken, denn es werden schlicht und ergreifend weniger Daten gesendet. Bei \"Low RWIN\" hat man zudem jedoch den Nachteil, dass die Pausen ein gewisses Lag-Gefühl hervorrufen - als Analogie kann man irgendwo im echten Leben langgehen und dabei ständig beide Augen auf und zu und auf und zu machen, so dass man seine Augen pro Sekunde etwa 5-10x schließt. Das, was man nun sieht bzw. nicht sieht, ist vergleichbar mit den durch \"Low RWIN\" ausgelösten Aussetzern während des Spielens.
Warum trifft man nun mit \"Low RWIN\" insgesamt besser? Das hängt damit zusammen, dass inzwischen viele Gameserver sich die Serverperformance mit zu vielen anderen Gameservern teilen müssen, wodurch entsprechend viele Gameserver ständig mit Leistungsengpässen umgehen müssen, d.h. ihre Tickrate fällt in wichtigen Situationen evtl. weit unter 100 Ticks pro Sekunde, was bedeutet, dass Datenpakete von vielen Spielern, deren cl_cmdrate höher ist als die Tickrate des Servers, ignoriert werden müssen - denn es steht keine freie Leistung mehr zur Verfügung, diese noch zu verarbeiten. Durch \"Low RWIN\" wird die cl_cmdrate künstlich verringert, einfach indem die Bandbreite eingeschränkt wird. Somit würde man durch eine Verringerung der cl_cmdrate, wie sie hier auf der Website beschrieben wird, das gleiche Ergebnis erzielen, während man die durch niedrigen RWIN entstehenden Sendepausen nicht über sich ergehen lassen muss.
Kompressionsarten
Im folgenden werden die verschiedenen Möglichkeiten zur Kompression zu übertragender Daten, sowie deren Vor- und Nachteile beschrieben.
IP Header Compression
Das TCP/IP-Protokoll, das im Internet verwendet wird, ist so konzipiert, dass vor jedem Datenpaket zuerst einige Kopfdaten gesendet werden, was allgemein unter dem Begriff Header bekannt ist. Dieser Header enthält unter anderem diverse Angaben zu dem jeweils folgenden Datenpaket sowie zur bestehenden Verbindung zwischen zwei IP-Adressen. Der Header ist in seinem normalen Zustand jedesmal exakt 40 Byte groß. Nun enthält er jedoch einige Werte, die sich oftmals die gesamte Verbindung über nicht ändern - warum müssen solche Informationen dann vor jedem Datenpaket immer wieder übertragen werden? Die so genannte Van-Jacobsen-Kompression beantwortet diese Frage mit einer Lösung: es wird einfach nicht mehr immer der gesamte Header gesendet, sondern nur noch das, was sich relativ zum jeweils vorherigen Header geändert hat, also beispielsweise die Größe des folgenden Datenpakets. So erreicht man durch jene \"Kompression\", dass die Header typischerweise nur noch 3-5 Byte in Anspruch nehmen. Dies ist der Zweck der Header-Kompression, obwohl in Wahrheit keinerlei Kompressionsalgorithmus verwendet wird. Einige im Header enthaltene Angaben werden einfach nur weitaus seltener versendet - einige sogar nur einmal pro Verbindung. Mit diesem Hintergrundwissen macht es nun Sinn, die Header-Kompression grundsätzlich immer aktiviert zu lassen.
Softwarekomprimierung
Um Daten, die transferiert werden sollen, so schnell wie möglich zu übertragen, macht sich allgemein das Prinzip der Kompression nützlich. Beispielsweise wird ein 20 Megabyte großes BMP-Bild für gewöhnlich weit weniger schnell übertragen als ein 200 Kilobyte großes JPG-Bild, das denselben Inhalt in komprimierter Weise enthält. Heutzutage sind die meisten Nutzdaten - MP3s, JPGs, AVIs, MPGs und so weiter - bereits komprimiert oder werden von Benutzern, bevor sie transferiert werden, noch mit entsprechenden Kompressionsprogrammen (Archivern, z.B. RAR oder ZIP) komprimiert. In diesem Sinne bringt die Softwarekomprimierung heutzutage weit weniger als noch vor 5 Jahren. Hat man sie dennoch aktiviert, wird nichtsdestotrotz vom Übertragungsprotokoll versucht, alle Daten zu komprimieren, bevor diese versendet werden. Ob diese letztenendes kleiner sind, kann das Übertragungsprotokoll natürlich vorher nicht sagen und versucht sich daher auch an jedem Archiv, an jedem MP3, also an restlos jedem zu transferierenden Datenpaket. Dies, da es softwareseitig geschieht, benötigt eine gewisse Rechenleistung, kann also für gewisse, wenn auch für die meisten Zwecke nicht spürbare Verzögerungen verantwortlich sein, welche größer sind als die im Bestfall gutgemachte Zeitersparnis durch die Kompression. Da in den meisten Multiplayerspielen die zu übertragenden Daten kaum noch komprimiert werden können, wäre es somit eine reine Zeit- und Performanceverschwendung, die softwareseitige Datenkomprimierung zu aktivieren.
Bandbreiten & Pings
Heutzutage werden von immer mehr Internetnutzern zwei verschiedene Eigenschaften einer Internetanbindung, die Bandbreite und die Pingzeiten, unter dem Begriff \"Geschwindigkeit\" zusammengefasst. So ist manch einer beispielsweise der Auffassung, dass die ISDN-Kanalbündelung (2 x 64 Kilobit/s = 128 Kilobit/s) bewirkt, dass der Ping der so gebündelten ISDN-Leitung gleichzusetzen ist mit einer Cable/DSL-Leitung, welche 128 Kilobit/s Upstream oder Downstream besitzt. Man stelle sich als Analogie eine Autobahn mit 3 Spuren vor, auf welcher alle Autos mit durchschnittlich 100 KM/h fahren. Verdoppelt man nun die Anzahl der Spuren, fahren die Autos dann schneller? Diese Antwort ergibt sich auch bei der ISDN-Kanalbündelung: selbst wenn man hunderte an ISDN-Kanälen bündeln würde, wäre keine sonderliche Pingverminderung feststellbar, da sich die bei ISDN verwendete Technik dadurch in keiner Weise verändert/verbessert, der Datenweg sich dadurch nicht im mindesten verkürzt und die Daten nach wie vor mit derselben Geschwindigkeit übertragen werden. Einzig die Bandbreite, also die Menge der Daten, die gleichzeitig übertragen werden kann, erhöht sich dabei.
Damit sollte klar sein, dass der Ping irgendeines Leitungstyps in keiner Weise mit dessen Bandbreite in Relation zu setzen ist. In diesem Sinne sollte ebenso klar geworden sein, dass es keinen Sinn macht, für verschiedene Geschwindigkeiten eines bestimmten Leitungstyps verschiedene Netzeinstellungen (Netsettings) aufzustellen, wie es im Bezug auf Multiplayerspiele von manchen Leuten bzw. auf manchen Websites gemacht wird, da es sich zum Beispiel bei T-DSL 1000, T-DSL 2000 und T-DSL 3000 in jedem Fall nur um DSL handelt, welches auf der gleichen Technik basiert, egal welche Bandbreite eingesetzt wird. Einzig die \"Datenautobahnen\" werden dabei verbreitert - die \"Autos\" fahren jedoch nicht schneller, nur weil mehr von ihnen gleichzeitig nebeneinander fahren können.
Der Scoreboard-Ping CS 1.6 & CS:SOURCE;
Oft genug sind Leute der Meinung, ihre spielerische Leistung hänge davon ab, wie hoch oder niedrig der im Scoreboard für alle Spieler sichtbare Ping ist. Dieser wird niedriger, je weniger Daten die Datenpakete, anhand welcher die Pingzeiten gemessen werden, enthalten. Nun soll der Ping den Datenweg zwischen zwei IP-Adressen repräsentieren, also den Weg, den die Daten durch das Internet zu nehmen haben, um von der einen IP zu der anderen zu gelangen. Dieser Datenweg wird sich jedoch nicht physikalisch verändern, nur weil man mehr oder weniger Daten sendet, sondern der Weg ist und bleibt - von gewissen chaotischen Schwankungen, die immer präsent sind, abgesehen - prinzipiell im Durchschnitt gleich. Warum nun die Pingzeit mit der Größe eines Ping-Datenpakets variiert, lässt sich schnell erklären: um den Ping zu ermitteln, wird eine Kette an Daten abgeschickt. Jedes Byte dieser Datenkette muss erst beim Server ankommen, bis dieser sie verarbeiten und als Antwort die Datenkette zurückschicken kann. Anschließend kommt die Antwort Byte für Byte wieder bei der Quelle an, wo die virtuelle Stoppuhr dann angehalten wird, wenn die Ping-Datenkette vollständig angekommen ist. Je länger diese Datenkette ist, desto länger dauert es zwangsläufig, bis sie vollständig beim Server angekommen ist und dieser sie zurückschicken kann. Anschließend dauert es, je länger die Datenkette ist, natürlich ebenso auch länger, bis sie wieder vollständig zurückgekommen ist. Der im Scoreboard angezeigte Ping wird genau dadurch ermittelt und ist daher leider nicht zu gebrauchen, da es keinen für das Spiel sinnvollen Zweck erfüllt, kleinstmögliche Ping-Datenketten zu versenden. Dieser Sachverhalt soll an den folgenden beiden Graphen verdeutlicht werden - in diesen wird der Ablauf dargestellt, wie ein 10-Byte-Ping und ein 40-Byte-Ping versendet werden:
Die hier verwendeten Zahlen sind natürlich nur Beispielwerte - es geht ausschließlich um die Tatsache, dass der Ping höher wird, je mehr Daten das Ping-Paket enthält. In Counter-Strike wird das für den Ping verwendete Datenpaket größer, je höher die eingesetzten Netsettings sind.
Der Netgraph-Ping
Der im Netgraph angezeigte Ping wird ähnlich berechnet wie jener im Scoreboard - es ist also nicht, wie so oft erzählt, der Fall, dass seit CS1.6 der Netgraph-Ping den wahren Ping widergibt. Das ist einfach damit erklärt, dass es nach wie vor nicht möglich ist, Daten in Nullzeit von Punkt A nach Punkt B zu versenden - man kann den Netgraph-Ping jedoch auf 0ms senken, wodurch daher nicht der reale Ping repräsentiert werden kann. Auch die Erklärung, dies sei der wahre Ping abzüglich der Lag-Compensation, kann nicht zutreffen, da man den im Netgraph angezeigten Ping durch die Variable \"cl_updaterate\" manipulieren kann. Somit müsste die Lag-Compensation, je nach Updaterate, mehr oder weniger aktiv sein und die Spieler-Server-Verzögerung eben mehr oder weniger gut kompensieren. Dies ist jedoch in CS1.6 und CS:S nicht der Fall - Hitboxen und Models haben sowohl in CS1.6 als auch in CS:S einen Abstand, der in CS1.6 fest und nur minimal ist, während dieser in CS:S durch das Maß an Interpolation bestimmt wird und auch nur durch Änderung der Interpolationsreichweite geändert werden kann.
Welcher Ping ist wichtig?
Prinzipiell ist der Ping völlig irrelevant bei der Wahl der Netsettings, da man diesen ohnehin durch kein Mittel der Welt ändern kann, sofern man nicht zu einer anderen Internetanbindung gelangt - es kommt einzig darauf an, jede Spielsekunde in so viele Teile wie möglich aufzuteilen, was durch entsprechend hohe Netsettings erzielt werden kann. Dabei muss man jedoch darauf achten, dass man mit zu hohen Netsettings nicht über der Tickrate eines Servers liegt, die aus leistungstechnischen Gründen durchaus niedriger als 100 sein kann und somit bei Netsettings mit cl_cmdrate 100 und cl_updaterate 100 zu leichten bis schweren Synchronisationsschwankungen, bzw. -störungen führen kann. Anders ausgedrückt: Die Netsettings sollten grundsätzlich nicht höher sein als die serverseitige Tickrate. Dies wird im Bereich Empfehlungen (CS1.6) bzw. Empfehlungen (CS:S) näher beschrieben.
Was ist die Tickrate?
Es existiert ein serverseitiger Kommandozeilenparameter in CS1.6 als auch in CS:Source, welcher in der Lage ist, die maximale Tickrate des Servers zu beeinflussen. Diese Tickrate bestimmt, wie oft der Server pro Sekunde sein \"Bild der Welt\" aktualisiert, also wie oft der Server in jeder Sekunde die Bewegungen aller Spieler und Items sowie alle Aktionen berechnet. Ohne diese ständige Neuberechnung würde das Spiel komplett stillstehen, so als existiere darin keine Zeitdimension. Die Tickrate bestimmt also, wie detailliert aus Sicht des Servers alles dargestellt wird, denn wenn es pro Sekunde nur eine Aktualisierung gäbe - so als würden Sie Ihre Augen nur einmal pro Sekunde ganz kurz öffnen - dann ist das deutlich ruckartiger als wenn es 30 oder gar 300 Aktualisierungen in jeder Sekunde geben würde.
Zwei verschiedene Tickrates:
Es werden allgemein zwei leicht verschiedene Dinge als Tickrate bezeichnet, welche an dieser Stelle erklärt werden. Zum einen ist da die serverseitige Anzahl der bereits genannten Aktualisierungen des \"Weltbildes\", welche durch die Tickrate bestimmt wird. Wenn diese beispielsweise serverseitig auf 33 begrenzt ist und ein Spieler 100 Updates pro Sekunde anfordert, so würde der Spieler jeweils drei völlig identische Updates am Stück erhalten, bevor sich der Inhalt des Updates ändert, einfach weil der Server sein Weltbild erst dann erneuert. Der Server ist hierbei also, sofern genügend Rechenleistung vorhanden ist, in der Lage, trotz niedrigerer Tickrate noch die volle Zahl an Updates zu verschicken. Ist jedoch die Tickrate nach oben hin offen, kann also je nach serverseitig verfügbarer Rechenleistung mehr oder weniger schwanken, so kann es vorkommen, dass die Tickrate die 100 unterschreitet - jedoch ist dann nicht nur die Tickrate, sondern auch die serverseitige Updaterate betroffen, also die Zahl der Updates, die der Server pro Sekunde an jeden Spieler verschicken kann, denn in solch einem Fall existiert einfach keine weitere Rechenleistung, noch mehr zu versenden. Wenn also die Tickrate aus Performancegründen auf unter 100 gedrückt wird, so ist auch dessen Updaterate davon betroffen und ein Spieler, der 100 Updates pro Sekunde vom Server anfordert, würde weniger als 100 Updates erhalten. Diese serverseitige Updaterate wird, obwohl es eigentlich nicht wirklich die Tickrate ist, allgemein als Tickrate bezeichnet. Ein weiteres Problem, welches mit der aus Performancegründen gedrückten Tickrate zusammenhängt, ist, dass der Server auch nur eine verminderte Anzahl an Aktionen (Datenpaketen) pro Sekunde je Spieler verarbeiten kann. Würde ein Spieler mit cl_cmdrate 100 spielen und sich auf einem Server befinden, der in wichtigen Situationen nur 50 Ticks berechnen kann, so würde auch nur im Durchschnitt jedes zweite Datenpaket, das von diesem Spieler kommt, vom Server erfasst und verarbeitet werden - die andere Hälfte dieser Datenpakete müsste, da keine Performance vorhanden ist, um diese zu verarbeiten, zwangsläufig ignoriert werden. Der einzige Ausweg aus Sicht eines Gameservers wäre es, den Spielfluss zu verlangsamen, so dass eine Spielsekunde beispielsweise auf zwei Echtzeitsekunden ausgeweitet wird, wodurch so etwas ausgeglichen werden würde. Jedoch ist solch eine Programmierung für diesen Fall bei praktisch keinem bekannten Shooterspiel vorhanden.
Hohe oder niedrige Tickrate?
Was ist nun besser? Eine serverseitige hohe oder eher niedrige Tickrate?
Es ist in der Tat je nach Rechenleistung so, dass nicht immer eine hohe Tickrate die bessere Wahl ist. Denn eine höhere Anzahl an Ticks pro Sekunde verbraucht serverseitig Rechenleistung, was, sofern davon nicht genügend vorhanden ist, dazu führen kann, dass auch die Anzahl der Updates und Spieleraktionen pro Sekunde unter 100 fällt, wodurch einerseits die Spieler weniger als 100 Updates jelten und andererseits Datenpakete von Spielern ignoriert werden nem Fall wäre es sinnvoller, die serverseitige Tickrate zu vermindern, wodurch genug Rechenleistung frei wird, damit der Server wenigstens 100 Datenpakete je Spieler je Sekunde verarbeiten kann, was aus Sicht aller Spieler die vermutlich deutlich bessere Alternative ist, verglichen mit \"Packetloss aus Performancegründen\".
Netzbezogene Consolenbefehle CS 1.6 & CS:SOURCE;
In diesem Abschnitt werden die für Netzverbindungen relevanten Consolenbefehle des Spiels Counter-Strike beschrieben - die beinhaltet keinerlei Empfehlungen oder Folgerungen, nur einige Beispiele. Alle hier nicht erwähnten Consolenbefehle besitzen bezüglich des Spielflusses nicht genügend Relevanz - dies bedeutet jedoch nicht, dass es keine weitere Befehle gibt, die einen netzbezogenen Einfluss in Counter-Strike haben.
rate
Die Variable \"rate\" gibt in Byte an, wie viele Daten pro Sekunde höchstens übertragen werden dürfen, stellt also eine Geschwindigkeitsbegrenzung dar. Ein zu niedriger \"rate\"-Wert bewirkt, dass in bestimmten Fällen Daten nicht oder nur verspätet versandt werden können, was das Spielgefühl negativ beeinflussen kann. Ein zu hoher Wert hat, sofern genug Bandbreite (8-16 KB/s je Datenrichtung) vorhanden ist, hingegen keine direkten Nachteile, da ohnehin nur so viele Daten verschickt werden, wie eben nötig sind. Einige Server besitzen Mindest- und Höchstgrenzen für den \"rate\"-Wert. Verschiedene Ligen haben in ihren Regelwerken ebenfalls unterschiedliche Begrenzungen, welche bei Ligaspielen beachtet werden sollten, da beispielsweise eine serverseitig zu niedrig eingestellte Höchstgrenze das Spielgefühl aller Spieler extrem verschlechtern kann.
cl_cmdrate
Über das Kommando \"cl_cmdrate\" wird bestimmt, wie viele Datenpakete pro Sekunde zum Server hin übertragen werden sollten. Counter-Strike sieht hierin kein Hardlimit (nicht überschreitbare Grenze), sondern nur ein Softlimit, welches in bestimmten Fällen auch überschritten werden kann. Je höher \"cl_cmdrate\" gewählt wird, in desto mehr Teile wird eine Sekunde beim Spielen zerlegt, was das Spielgefühl in den meisten Fällen erheblich verfeinern kann, sofern man auch windowsseitig den MTU-Wert entsprechend gesenkt hat, damit eine Sekunde tatsächlich in so-und-so-viele Pakete pro Sekunde aufgeteilt werden kann. Ansonsten würde die Aufteilung nicht so fein sein, da bei einem entsprechend hohen MTU-Wert meist mehrere CS-Aktionen/CS-Datenpakete als ein einziges, zusammengefasstes Datenpaket verschickt werden (was üblicherweise auch bei niedriger cl_cmdrate der Fall ist), wenn jene CS-Datenpakete von der Größe in Byte her einzeln zu klein wären.
Standardwert: 30
cl_updaterate
Als Gegenstück zu cl_cmdrate bestimmt die Variable \"cl_updaterate\", wie viele Datenpakete (Updates) der Server pro Sekunde zum Spieler übertragen soll. Ähnlich wie bei cl_cmdrate, sieht Counter-Strike hierin kein Hardlimit (nicht überschreitbare Grenze), sondern ebenfalls ein Softlimit, welches in einigen wenigen Situationen überschritten werden kann. Die Erhöhung von \"cl_updaterate\" ist durchaus sinnvoll. Zwar extrapoliert (berechnet) Counter-Strike alle fehlenden Elemente, die durch zu wenige Updates je Sekunde nicht vorliegen, so genau wie möglich, jedoch kann es dabei vorkommen, dass dem Spieler einige Details, die ZWISCHEN dem Versand zweier Datenpakete geschehen, komplett entgehen oder erst zu spät zugesandt werden, was bei einem erhöhten Wert nicht der Fall gewesen wäre. Serverseitig ist es möglich, diesen Wert nach oben hin zu begrenzen, so dass ein Spieler ggf. mehr Updates pro Sekunde anfordern kann, als es der Server zulässt.
Standardwert: 20
cl_cmdbackup
\"cl_cmdbackup\" gibt an, wie oft ein Datenpaket nachträglich erneut an den Server gesendet werden kann. Dies hat zum Hintergrund, dass es vorkommen kann, dass Datenpakete manchmal nur verspätet oder gar nicht ankommen - ist es jedoch unbedingt notwendig, dass ein Datenpaket ankommt, was bei Multiplayerspielen selbstverständlich notwendig ist, kann es einfach immer wieder gesendet werden, bis schließlich mindestens eines davon ankommt und vom Server bestätigt wird.
Standardwert: 2
Was ist wichtig? CS 1.6 & CS:SOURCE
In einem in Echtzeit laufenden Spiel wie Counter-Strike ist es unbedingt notwendig, dass jede Aktion des Spielers so schnell wie möglich vom Server erfasst und verarbeitet wird. Gleichzeitig ist es notwendig, dass der Spieler alle vorhandenen Informationen so schnell wie möglich vom Server erhält. Dazu ist es erst einmal wichtig, den Menüpunkt Wissenswertes gelesen zu haben, welcher Details über die windowsseitige Netzwerk-Variable MTU (Maximum Transfer Unit) enthält, die für Counter-Strike so essentiell wichtig ist wie die CS-eigenen Netzbefehle. Im folgenden wird desweiteren erklärt, was bei den wichtigsten Netzbefehlen von CS zu beachten ist.
rate
Diese Variable sollte man aus mehreren Gründen auf einen für Transferraten unerreichbar hohen Wert stellen und anschließend einfach vergessen. Für gewöhnlich genügt dafür ein Wert ab 15000, unabhängig von Typ und Geschwindigkeit der Internetanbindung. So hat man letztenendes eine Sache weniger, um die man sich kümmern muss - denn eigentlich relevant sind nur die Variablen, die bestimmen, wie viele Pakete je Sekunde übertragen werden. Zudem gibt es keinen Grund, \"rate\" zu verändern, wenn man einen Server betritt, der Mindest- oder Höchstgrenzen für diese Variable einsetzt, da sich Counter-Strike automatisch an diese Grenze anpasst, sollte \"rate\" zu hoch (oder zu niedrig) sein. Letztenendes ist es zudem egal, ob man nun 15000 oder 50000 verwendet, da die Menge an Daten, die pro Sekunde im Höchstfall aufgebracht werden kann, weniger als 15000 Byte beträgt, so dass man sich um die Bytes pro Sekunde (also um \"rate\"), wenn es nur hoch genug eingestellt ist, keine weiteren Sorgen zu machen braucht. Auch bei Choke während des Spiels, also beim Ankommen von Datenpaketen in der falschen Reihenfolge, ist der \"rate\"-Befehl unwichtig - in jenem Fall ist nur \"cl_updaterate\" von Relevanz.
cl_cmdrate
Die meisten Server sind von ihrer Leistung her in der Lage, sekündlich mehr als 100 \"Bilder der Welt\" (Ticks) zu berechnen, so dass es sinnvoll ist, diese auch zu nutzen und nicht nur etwa 30 oder 50 Bilder je Sekunde zum Server zu schicken - mit \"Bilder\" sind hierbei keine visuellen Bilder gemeint, sondern Momentaufnahmen von jeweils allem, was gerade auf dem Server aktuell ist, d.h. Positionen aller Spieler sowie aller Items, die auf der Map herumliegen. Hierbei spielt es keine Rolle, was menschliche Augen zu tun oder nicht zu tun vermögen - es geht nur darum, dass eine Aktion, die ein Spieler durchführt, immer erst mit dem jeweils nächsten Datenpaket an den Server geschickt werden kann. Führen wir dazu ein Gedankenexperiment durch: stellen wir uns vor, man versendet nur ein einziges Datenpaket pro Sekunde an den Server, welches alles beinhaltet, was der Spieler seit dem jeweils vorangegangenen Datenpaket getan hat, also ein Datenpaket mit den Daten einer ganzen Sekunde. Schießt der Spieler am Anfang dieser Sekunde auf einen Gegner, würde diese Information erst in etwas weniger als einer Sekunde an den Server geschickt werden, was also zu einer enormen Verzögerung führt, die man zusätzlich zur reinen Übertragungszeit (Ping) hätte. Erhöhen wir das ganze nun auf zwei Datenpakete pro Sekunde: nun ist das ganze schon etwas besser, denn immerhin müsste man in der eben genannten Situation nur noch etwas weniger als eine halbe Sekunde warten, bis das Datenpaket zum Server geschickt wird. Die Erhöhung von \"cl_cmdrate\" kann man nun soweit fortsetzen, wie man möchte, und es erweist sich, dass wir, je weiter \"cl_cmdrate\" erhöht wird, man die eigenen Aktionen immer rascher an den Server übertragen kann, sich also immer mehr in Echtzeit auf dem Server austoben kann. Zu empfehlen ist hierbei 100 - manche bevorzugen 101, was jedoch prinzipiell keinen Unterschied macht, da Counter-Strike die empfangenen Daten selbständig mit den berechneten Bildern zu synchronisieren vermag. Auch die Erklärung, durch +1 Datenpakete pro Sekunde hätte man eine Sicherheit, falls mal eines ausfällt, basiert auf keiner sinnvollen Grundlage, da das zusätzliche Datenpaket im Falle des Verlusts von einem der anderen 100 Datenpakete niemals die Daten des verlorenen Datenpakets enthalten würde. Zurück zum Thema: Es gibt jedoch auch Server, welche an die 100 Bilder je Sekunde nicht herankommen - entweder ist der Prozessor ansich nicht leistungsfähig genug oder es laufen zu viele Programme (z.B. Gameserver) auf dem Serverrechner, welche sich die Prozessorleistung zwangsläufig teilen müssen. In diesem Fall ist es das sinnvollste, \"cl_cmdrate\" während des Spielens, sollte das Spielgefühl unregelmäßig oder ungleichmäßig sein, immer etwas zu senken, bis das Spielgefühl plötzlich konstant wird. Dass man den richtigen Wert getroffen hat, merkt man vor allem daran, dass der Server jedes Datenpaket, also jede Aktion korrekt erfasst - das heißt, dass man plötzlich dahin trifft, wo man hinzielt, und nicht mehr in die Wand hinter dem Gegner. Bei solchen Servern ist noch zu beachten, dass sie immer leistungsschwächer werden, je mehr Spieler darauf spielen. Mit steigender Spielerzahl sollte man also die \"cl_cmdrate\" weiter senken, während man den Wert steigern kann, je weniger Spieler auf dem Server sind.
cl_updaterate
Standardmäßig gilt die Erklärung, welche hier für \"cl_cmdrate\" gegeben wurde, auch für \"cl_updaterate\" - jedoch mit dem Unterschied, dass man, bevor man einen Server betritt, nachsehen sollte, ob dieser ein Maximum für \"cl_updaterate\" fordert. Der serverseitige Befehl dazu lautet sv_maxupdaterate und kann nicht über die Konsole im Spiel abgefragt werden, da man darüber nur den bei sich selbst eingestellten Wert für sv_maxupdaterate ermittelt, welcher auf dem jeweiligen Server völlig ohne Belang und somit wertlos ist. Notfalls kann man dies auch während des Spielens noch feststellen, sofern man einen Blick auf den Netgraph wirft - ein \"cl_updaterate\"-Wert oberhalb des serverseitigen Maximums führt dazu, dass der Server die angeforderten Datenpakete, sofern mehr als die bereits versendeten Informationen serverseitig überhaupt verfügbar sind, nicht immer liefern kann und daher puffert, bis zu einem Zeitpunkt weniger Informationen als maximal erlaubt/möglich versendet werden, wodurch Bandbreite frei wird, um die vormals gepufferten Daten nachträglich zu versenden, was zu einem (verzögerten) Anstieg von Choke im Netgraph führt. In solch einem Fall ist es wichtig, den Wert dafür unbedingt auf weniger als den Maximalwert festzulegen, da alles, was darüber hinaus geht, clientseitig (also beim Spieler) zu Synchronisierungsstörungen führen und somit das Spielgefühl ganz entscheidend beeinträchtigen kann. Warum man weniger wählen sollte, ist schnell erklärt: Counter-Strike hält sich nicht immer an die Grenzen für \"cl_cmdrate\" und \"cl_updaterate\", versendet also je nach Situation mal mehr, mal weniger Daten als maximal erlaubt. Setzt man nun für \"cl_updaterate\" den maximal vom Server zugelassenen Wert, riskiert man, dass Counter-Strike aus programmtechnischer \'Dummheit\' diesen überschreiten kann - das ist vor allem dann der Fall, wenn gerade sehr viel passiert, also wenn sich etwa jeder Spieler bewegt, dabei schießt und/oder Granaten wirft. Es spielt dabei keine Rolle, ob der Spieler dies selbst sehen/hören kann, da die Ereignisse in seiner Umgebung auf jeden Fall vom Server an ihn übertragen werden.
cl_cmdbackup
Da es die Aufgabe von \"cl_cmdbackup\" ist, Datenpakete mehrfach zu senden, um dessen Empfang sicherzustellen, ist der Wert situationsbedingt und nicht pauschal für diese oder jene Internetanbindung festlegbar. Das Internet ist nicht gleichförmig - die meisten Wege, die die Daten von einem Spieler zu einem Gameserver hin nehmen, sind zwar sicher und im übertragenen Sinne \'gut gepflastert\', aber Ausnahmen bestätigen diese Regel leider. Bei den gut gepflasterten Datenwegen kann man \"cl_cmdbackup\" problemlos völlig abschalten, also auf den Wert 0 setzen. Dies hat den Vorteil, dass keine Bandbreite unnötig zum Versenden von Duplikaten verwendet wird und die restlichen (originalen) Datenpakete allesamt etwas schneller ankommen, was in einigen Randsituationen innerhalb des Spiels enorm wichtig sein kann. Die Ausnahmefälle zu der genannten Regel haben nicht immer die jeweiligen Server als Ursache - normalerweise ist es so, dass in solch einem Fall der Datenweg zwischen Server und Spieler einige Probleme enthält: völlig überlastete Rechner oder Router, die als Zwischenstation (Hop) dienen, Daten manchmal sehr verzögert weitersenden, was dazu führt, dass die Daten Ausweichwege nehmen - das versteht man unter dem Wort Redundanz. In diesem Fall, wenn man das Problem angehen möchte, sollte man versuchen, bei den überlasteten Problem-Hops eine höhere Priorität zu erhalten, damit die eigenen Daten also mit höherer Wahrscheinlichkeit vor den meisten anderen versendet werden. Natürlich kann man mit Routern nicht reden, aber man kann sie überlisten, indem man jedes Datenpaket einfach immer und immer wieder schickt - so addieren (eigentlich multiplizieren) sich die Wahrscheinlichkeiten jedes einzelnen Datenpakets, durch je einen Problem-Hop zu gelangen. Würde ein Datenpaket zum Beispiel mit 10% Wahrscheinlichkeit sein Ziel nicht erreichen, so könnte man diese Wahrscheinlichkeit immer weiter senken, je öfter man das entsprechende Datenpaket verschickt. Verschickt man es beispielsweise 5-mal, sinkt die Chance auf 0,10 ^ 5 = 0,00001, also auf 0,01‰ (Promille), dass überhaupt keins der Datenpakete sein Ziel erreicht. Damit steigt die Wahrscheinlichkeit, dass mindestens eines den Weg zum Server findet.
Loss und Choke CS 1.6 & CS:SOURCE
Der Netgraph von Counter-Strike enthält unter anderem die zwei verbindungsbezogenen Angaben Loss und Choke, die in der Lage sind, Verbindungsprobleme mit leichten Verzögerungen anzuzeigen - im Folgenden werden sie erklärt.
Erklärung: Loss
Der Loss-Wert zeigt an, wann Datenpakete offensichtlich verloren gegangen sind - jedoch kann Counter-Strike nie definitiv sagen, ob ein Paket tatsächlich im Datennirvana verschwunden ist oder ob es nur mit einer enormen Verzögerung später noch ankommen wird. In diesem Sinne wertet Counter-Strike jedes ausgebliebene Datenpaket, das nach einer bestimmten Anzahl an Sekunden noch immer nicht angekommen ist, als verlorenes Paket, also als Packetloss. Da jedoch immer erst nach einigen Sekunden gesagt werden kann, ob diese Zeitspanne (Timeout) überschritten ist, ist der Loss-Wert, wie man ihn im Netgraph sieht, immer um entsprechend viele Sekunden verzögert - sieht man, dass der Loss-Wert ansteigt, ist der Paketverlust eigentlich bereits vor mehreren Sekunden passiert und unter Umständen gar nicht mehr aktuell. Die Timeout-Zeit, also auch die Verzögerung der Loss-Anzeige selbst, müsste sich in einer Größenordnung von 10 (+/- 4) Sekunden aufhalten. Die Loss-Anzeige zeigt nicht an, wie viele Pakete verloren gegangen sind, sondern die Prozentzahl der Pakete - das erklärt, warum Loss 100 nicht überschritten werden kann.
Die Ursache für Packetloss ist für gewöhnlich ein Problem technischer Natur - ein nicht mehr ordnungsgemäß funktionierender Router oder ein RJ45-Netzwerkkabel mit Kabelbruch zumeist. Das Problem kann also nur behoben werden, indem man die technische Ursache dafür erkennt und behebt. Temporär ist es währenddessen dennoch möglich, Counter-Strike zu spielen - es ist dann jedoch notwendig, den in CS vorhandenen Befehl \"cl_cmdbackup\" auf einen möglichst hohen Wert zu stellen. Setzen Sie den Wert einfach auf 100, da dies eine Größenordnung ist, die für gewöhnlich selbst bei extremen Technikproblemen noch problemlos genügt, was man durch Wahrscheinlichkeitsrechnung verständlich machen kann: mit jedem versendeten Paket eines Duplikats sinkt die Wahrscheinlichkeit, dass keines der versendeten Pakete ankommt, um eine Potenz. Bei bis zu 100 Duplikaten sinkt eine Chance von 50% Ausfallwahrscheinlichkeit auf eine unfassbar kleine Zahl (0.50 ^ 100, mit 100 multipliziert erhält man so eine Packetlosswahrscheinlichkeit von nur noch ca. 0,000.000.000.000.000.000.000.000.000.08%). Der Nachteil daran ist jedoch, dass man nicht sagen kann, welches Duplikat den Server als erstes erreicht hat - das wiederrum kann eine falsche Reihenfolge an beim Server eingehenden Datenpaketen verursachen, was vergleichbar mit Choke ist, jedoch im Netgraph nicht angezeigt wird.
Erklärung: Was Choke NICHT ist
Von einigen Leuten, die man teils international gemeinhin als Experten im Bezug auf Netsettings anerkannt hat, stammt eine Erklärung für Choke, die ich zuerst einmal widerlegen möchte/muss, bevor die eigentliche Beschreibung von Choke folgt. In ersterer Erklärung wird gesagt, Choke gibt an, mit wie vielen Datenpaketen der Server gerade aufgrund von temporärer Leistungsschwäche nicht dienen kann. In welcher Einheit wird der Choke-Wert laut dieser Erklärung angezeigt? Leider ist dies bei jener Erklärung nicht ersichtlich, so dass ich im Folgenden die einzigen, Sinn machenden Möglichkeiten durchgehen möchte:
1. Wenn Choke die Anzahl der Datenpakete pro Sekunde ist, die einfach ausbleiben, so ist es nicht möglich, einen Choke-Wert zu erhalten, der sichtbar über der jeweils gewählten cl_updaterate liegt. \"Sichtbar darüber\", weil cl_updaterate technisch nur ein Softlimit ist, also bei Notwendigkeit auch leicht überschritten werden kann. Es hat jedoch in der Vergangenheit bereits hunderte Fälle gegeben, in welchen selbst Leute mit cl_updaterate 50-90 einen Choke von 100 vorweisen konnten - somit fällt diese Möglichkeit schon einmal weg.
2. Die zweite, sinnvolle Möglichkeit wäre die Angabe der Datenpakete pro Sekunde in Prozent, so dass beispielsweise ein Choke von 6 bedeuten würde, dass unabhängig von cl_updaterate 6% der Datenpakete nicht geliefert werden konnten. Auf den ersten Blick macht das Sinn, da es sonst keinen Grund gibt, warum Choke einen Maximalwert von 100 nicht überschreiten können sollte. In diesem Fall müsste der vom Server an den Spieler gehende Datenstrom gänzlich wegfallen, wenn man Choke 100 erreicht hat, da der Server dann nur mit 0% der angeforderten Daten dienen kann, also gar keine Daten mehr an den Spieler schickt. Das ist aber nicht der Fall, was sehr viele Spieler, die in ihrem Leben schon einmal Choke 100 hatten, bestätigen können.
Somit wurden nun die einzigen, sinnvollen Möglichkeiten jener Erklärung für Choke ausgeschlossen. Von jemandem, dessen Name hier selbstverständlich nicht genannt wird, möchte ich diesen Satz hier zitieren: \"Einheit? Wieso sollte man diesen Wert denn in einer Einheit anzeigen? Deine Erklärung hinkt!\" In diesem Sinne trinke ich pro Tag fünf. Fünf was? Fünf ... Eimer Wasser? Fünf Kubikzentimeter reinen Alkohol? Fünf Liter Tee? Und natürlich spiele ich pro Tag etwa zwei. Zwei was? Zwei Onlinespiele? Zweimal Strip-Poker mit meiner Nachbarin? Zwei Partien Schach? Zweimal Counter-Strike am Tag? Wie man sieht, ist die Angabe eines Wertes ohne eine dazugehörige Einheit absolut sinnlos. Wäre dies im Falle von Choke tatsächlich wahr, könnte man den Choke-Wert nicht gebrauchen, ebenso wie man die eben genannten Sätze (\"Ich trinke pro Tag fünf und spiele pro Tag etwa zwei.\") nicht gebrauchen kann, ohne eine Einheit zu den Zahlen anzugeben.
Erklärung: Choke
Choke zeigt an, wie viele Datenpakete, die der Server zum Spieler schickt - die andere Datenrichtung also, verglichen mit dem Loss-Wert - in der falschen Reihenfolge beim Spieler eintreffen. Da die Messung, wie auch bei Loss, immer eine gewisse Zeit benötigt, wird der Choke-Wert also nicht in Echtzeit angezeigt, sondern immer um eine kurze Zeit verzögert. Bei Choke ist diese Verzögerung jedoch nur minimal, da die falsche Reihenfolge an Paketen dadurch ermittelt wird, dass jedes Datenpaket mit einer laufenden Zahl \'numeriert\' wird - kommt nach Datenpaket Nummer 500 plötzlich Datenpaket Nummer 502 an, ist mindestens ein Datenpaket, nämlich Nr. 501, nicht in der richtigen Reihenfolge. Als nächstes wird noch ermittelt, wann das fehlende Datenpaket eintrifft. Wird dies registriert, taucht im Netgraph ein Anstieg des Chokewertes auf. Wie bei dem Loss-Wert, müsste auch hierbei theoretisch ein Timeout existieren, das Datenpakete, die zu viel Zeit benötigen, nach einer festgelegten Zeit automatisch als Choke registrieren, obwohl sie dann noch immer nicht eingetroffen sind. In diesem Sinne zeigt der Chokewert als indirekte Folge seiner eigenen Messung auch an, ob Pakete vom Server zum Spieler verloren gegangen sein könnten - jedoch vermischt mit den Paketen, die \'nur\' verspätet ankommen.
Verursacht wird das verspätete Eintreffen von Datenpaketen oftmals durch die zu starke Überlastung eines Hops - also eines Punktes auf dem Weg vom Server zum Spieler - bzw. des Servercomputers ansich, welcher ab einer gewissen Menge an Daten, die geroutet werden müssen, Prioritäten setzen und zu viele Daten von einer Quelle aufbewahren, bis genügend Bandbreite frei wird, um die Daten nachträglich zu versenden. Wenn so etwas passiert, dann passiert es für gewöhnlich sehr häufig in Bruchteilen einer Sekunde - so wie es hier geschrieben ist, könnte ansonsten die Vermutung aufkommen, dass das nur langsam und innerhalb mehrerer Sekunden passiert, was jedoch Unsinn ist. In diesem Sinne kann man Choke vermindern, indem man in Counter-Strike die Variable \"cl_updaterate\" senkt und dadurch weniger Datenaufkommen verursacht. Sofern die Überlastung direkt bei der Serveranbindung oder bei einem Hop, welcher zumindest beinahe jeder Spieler passieren muss, liegt, würde es noch mehr helfen, wenn jeder Spieler auf dem Server seine \"cl_updaterate\" senkt - in diesem Sinn ist die serverseitige Variable sv_maxupdaterate, die jene Beschränkung erzwingen kann, durchaus sehr nützlich. Würde Choke die andere Datenrichtung messen, also die vom Spieler zum Server, bekäme man das Problem mit der Variable \"cl_cmdrate\" in den Griff, was jedoch nicht der Fall ist - damit ist belegt, welcher Datenweg für den Choke-Wert gemessen wird.
Wird im Netgraph Choke 100 angezeigt, bedeutet dies jedoch nicht, dass 100% aller Pakete, die der Server zum Spieler sendet, nicht ankommen - dies liegt zwar theoretisch im Bereich des Möglichen, jedoch zeigt Choke hauptsächlich an, wieviel Prozent an Datenpaketen in der falschen Reihenfolge beim Spieler eintreffen. Wenn nun über einen längeren Zeitraum hin die \'numerierten\' Datenpakete beispielsweise in der Reihenfolge \"2, 1, 4, 3, 6, 5, 9, 7, 8, 11, 10, 15, 14, 12, 13, ...\" ankommen, ist keines davon an seinem vorbestimmten Platz und man erhält somit einen Choke-Wert von 100. Leider zeigt der Choke-Wert nicht an, welches Ausmaß die falschen Positionen der Datenpakete hat - denn an diesem könnte man viel eher erkennen, ob es sich lohnt, etwas dagegen zu unternehmen oder nicht. Bislang ist es nur möglich, dies am Spielgefühl festzustellen, wobei hier jedoch eine psychologische Komponente hinzukommt, die manch einen Spieler denken lässt, Choke sei in jedem Fall schlimm, obgleich man nicht selten mit einem Choke-Wert von 100 problemlos spielen kann.
Empfehlungen CS 1.6
Zunächst einmal wird empfohlen, den Menüpunkt Wissenswertes zu lesen, damit man sich über die Auswirkungen des enorm wichtigen MTU-Wertes im Klaren ist und diesen für Onlinegaming optimiert. Aufgrund der Unterschiede in der Beschaffenheit des Internet - der eine Datenweg ist besser, der andere schlechter - sollte man sich verschiedene Netsettings vorbereiten, die man notfalls im Spiel nachträglich einsetzen kann. In diesem Sinne sollte man sich je ein Paar Netsettings (jeweils cl_cmdrate, cl_updaterate, cl_cmdbackup) für die jede der denkbaren Situationen vorbereiten - in diesem Sinne wird empfohlen, die folgenden Zeilen in die eigene userconfig.cfg aufzunehmen:
rate 25000
alias net1 \"cl_cmdrate 100; cl_updaterate 100; cl_cmdbackup 0; echo cmd-100 / upd-100 / backup-0\"
alias net2 \"cl_cmdrate 50; cl_updaterate 50; cl_cmdbackup 0; echo cmd-50 / upd-50 / backup-0\"
alias net3 \"cl_cmdrate 30; cl_updaterate 30; cl_cmdbackup 100; echo cmd-30 / upd-30 / backup-100\"
alias net4 \"cl_cmdrate 100; cl_updaterate 27; cl_cmdbackup 100; echo cmd-100 / upd-27 / backup-100\"
alias net5 \"cl_cmdrate 30; cl_updaterate 100; cl_cmdbackup 100; echo cmd-30 / upd-100 / backup-100\"
net1
Der Ordner, in welchem sich die .cfg-Dateien befinden, lautet:
\\Steam\\SteamApps\\[DeinSteamLogin]\\counter-strike\\cstrike\\
Da die userconfig.cfg immer erst nach der config.cfg ausgeführt wird, werden dadurch standardmäßig beim Starten von Counter-Strike die in dem Alias net1 befindlichen Netsettings geladen. Man kann diese dann nachträglich ändern, indem man die Console öffnet und (net1,) net2, net3, net4 oder net5 eintippt - die Aliases auf Tasten zu binden, könnte hingegen für Verwirrung sorgen, da es nicht mehr ohne weiteres die Möglichkeit gibt, per Echo-Befehl ausgegebenen Text ohne die Console anzeigen zu lassen. Es gibt zwar einen Weg - dieser ist jedoch, obgleich technisch unbedenklich, nicht unbedingt in jeder Liga gestattet. Daher ist die Lösung auf dieser Website schlicht die Eingabe der Aliases über die Console - auf diese Weise weiß man auch, welche Werte man jeweils genommen hat.
Für welche Situationen sind die fünf Netsettings-Aliases nun gedacht?
net1: Hohe Netsettings für optimale Verbindung zu optimalem Server.
net2: Verminderte Netsettings, sollte ein Server leistungsbedingt die notwendigen Bilder pro Sekunde nicht berechnen können. Hierdurch werden dadurch verursachte Folgen unterbunden, solange der Server mehr als 50 FPS berechnet.
net3: Selber Grund wie net2, jedoch für Extremfälle gedacht --- Zusätzlich auch bei Packetloss sinnvoll und allgemein als absolute Notlösung gedacht.
net4: Falls ein Server mit sv_maxupdaterate 30 läuft, ist hierbei cl_updaterate noch um weitere 10% niedriger, da jener Wert manchmal überschritten wird (werden muss) und dennoch nicht das serverseitige Maximum überschreiten sollte, was ansonsten zu Synchronisierungsstörungen und somit zu spürbaren Verzögerungen führen kann.
net5: Durch hohe cl_updaterate ist man immer auf dem aktuellen Stand, während man durch die niedrige cl_cmdrate dem Problem mit den serverseitigen Ticks pro Sekunde umgehen kann. Ist in ein paar Fällen besser als die restlichen, hier beschriebenen Netsettings.
Hinweis: Einzelschuss CS 1.6
Da der Netcode in Counter-Strike sehr eigensinnig ist, sollte man sich die folgende Eigenart mal auf der Zunge zergehen lassen:
1. Schießt man je einen Schuss ab, kommt dieser unterhalb einer gewissen Schussfrequenz mit 100%iger Wahrscheinlichkeit dort an, wo man ihn hinschießt.
2. Schießt man Feuerstöße à 2 Schuss, kommt auf über 98% aller Server nur der erste an. (Es scheint der zweite Schuss zu sein - jedoch muss man die Übertragungsverzögerung hinzurechnen, woraus sich letztlich ergibt, dass es sich tatsächlich um den ersten Schuss handelt) Manche Server werten Schuss Nr. 2 als existent, jedoch nicht als Treffer - andere Server hingegen sagen, es gab nur einen Schuss, während wieder andere sagen, es gab 3 oder 4 Schüsse.
3. Schießt man Feuerstöße à 3 Schuss, kommt auf über 98% aller Server der erste sowie der dritte an, der zweite jedoch nicht.
Und diese seltsame Eigenschaft hängt definitiv nicht von den Bildern pro Sekunde ab, die Client (Spielerrechner) oder Server erreichen - wäre das der Fall, würde diese Eigenart nur auf etwa 5% aller Gameserver auftreten, was völlig der Statistik widerspricht und somit ausgeschlossen werden kann. Eine logische Erklärung, die nicht direkt mit dem Netcode zu tun hat, lässt bisweilen auf sich warten.
Es ist also absolut empfehlenswert, auf jede Distanz ausschließlich per Einzelschuss zu feuern, da jede andere Feuerfrequenz eine Trefferquote von weniger als 100% garantiert - dabei sollte man nicht auf die auf manchen Servern installierten Statistiken achten, da diese oft genug völligen Unsinn von sich geben. Hier ein paar Beispiele, bezogen auf 1on1-Spiele:
1. Man feuert in einer Runde genau zwei Schuss ab. Der erste ist ein Headshot und tötet den Gegner. Die Statistik ermittelt eine Trefferquote von 40% - wie ist das möglich? Zwei Schuss erlauben nur 0%, 50% oder 100%, aber niemals 40%. Die einzige partielle Erklärung ist, dass der Netcode mindestens fünf Schüsse gewertet hat, was das Minimum ist, um 40% Trefferquote zu erhalten, sofern es keine halben Schüsse gibt.
2. Man wirft zwei Flashbangs, eine Smokegrenade und eine HE auf einen Gegner und schießt ihn anschließend mit 4 Schuss (4 Treffern) aus einer AK nieder. Die Statistik ermittelt 57,78% Trefferquote - aber alle 4 Schuss haben getroffen, soviel steht fest. Die Statistik rechnet die Granaten mit, wobei die Flashbangs und Smokegrenades grundsätzlich als Nichttreffer gewertet werden. Damit kann erklärt werden, warum nur nahezu Fünf Achtel Trefferquote errechnet worden sind. Doch wenn 4 Schüsse aus der AK getroffen haben, müssten es etwa 4,5% mehr sein - auch hier wieder ein Rätsel der CS-Statistiken.
Empfehlungen CS:SOURCE
Zunächst einmal wird empfohlen, den Menüpunkt Wissenswertes zu lesen, damit man sich über die Auswirkungen des enorm wichtigen MTU-Wertes im Klaren ist und diesen für Onlinegaming optimiert. Aufgrund der Unterschiede in der Beschaffenheit des Internet - der eine Datenweg ist besser, der andere schlechter - sollte man sich verschiedene Netsettings vorbereiten, die man notfalls im Spiel nachträglich einsetzen kann. In diesem Sinne sollte man sich je ein Paar Netsettings (jeweils cl_cmdrate, cl_updaterate, cl_cmdbackup) für die jede der denkbaren Situationen vorbereiten - in diesem Sinne wird empfohlen, die folgenden Zeilen in die eigene userconfig.cfg oder autoexec.cfg aufzunehmen:
rate 25000
alias net1 \"cl_cmdrate 100; cl_updaterate 100; cl_cmdbackup 0; echo cmd-100 / upd-100 / backup-0\"
alias net1b \"cl_cmdrate 100; cl_updaterate 100; cl_cmdbackup 100; echo cmd-100 / upd-100 / backup-100\"
alias net2 \"cl_cmdrate 80; cl_updaterate 80; cl_cmdbackup 0; echo cmd-80 / upd-80 / backup-0\"
alias net3 \"cl_cmdrate 50; cl_updaterate 50; cl_cmdbackup 0; echo cmd-50 / upd-50 / backup-0\"
alias net4 \"cl_cmdrate 30; cl_updaterate 27; cl_cmdbackup 100; echo cmd-30 / upd-27 / backup-100\"
net1
cl_interp 0
cl_interpolate 0
Der Ordner, in welchem sich die .cfg-Dateien befinden, lautet:
\\Steam\\SteamApps\\[DeinSteamLogin]\\counter-strike source\\cstrike\\cfg\\
Sofern man diese Zeilen in eine CFG-Datei einfügt, welche noch vor der config.cfg ausgeführt wird - z.B. in die autoexec.cfg - so sollte man aus der config.cfg die Befehle rate, cl_cmdrate, cl_updaterate und cl_cmdbackup entfernen und die config.cfg anschließend mit einem Schreibschutz versehen, so dass CS:Source sie nicht wieder einfügen kann. Dies hat den Hintergrund, dass ansonsten nach den hier genannten Net-Aliases die gesetzten Netzbefehle wieder durch die config.cfg geändert werden würden, was nicht erwünscht ist.
Falls man die obigen Zeilen hingegen in eine CFG-Datei einfügt, welche erst nach der config.cfg ausgeführt wird - dafür muss ein entsprechender exec-Befehl am Ende der config.cfg stehen; die config.cfg muss dabei schreibgeschützt sein, da CS:Source den exec-Befehl sonst von sich aus wieder entfernt - so braucht man sich um eine Beeinflussung durch die config.cfg keine Sorgen zu machen.
Man könnte zusätzlich die fünf Net-Aliases in der config.cfg auf fünf Tasten binden, welche man nur nachträglich zu drücken braucht, um während des Spiels auf andere Netsettings zu wechseln.
Für welche Situationen sind die fünf Netsettings-Aliases nun gedacht?
net1: Hohe Netsettings für optimale Verbindung zu optimalem Server mit permanent 100 oder mehr Ticks pro Sekunde.
net1b: Sollte ein Server ansich optimal sein, die eigenen Daten jedoch durch einen problematischen (verzögernden) Hop geroutet werden, bewirkt das hohe cl_cmdbackup aufgrund der höheren Datenmenge eine höhere Priorität bei dem Problem-Hop, wodurch die Datenpakete des Spielers mit höherer Wahrscheinlichkeit beim Server eintreffen.
net2: Verminderte Netsettings, sollte ein Server leistungsbedingt die notwendigen \"Weltbilder\" pro Sekunde nicht berechnen können. Hierdurch werden dadurch verursachte Folgen unterbunden, solange der Server mehr als 80 FPS berechnet.
net3: Niedrige Netsettings, sollte man einen Server erwischen, dessen Tickrate in wichtigen Situationen zwar vermindert ist, jedoch höher als 50 bleibt.
net4: Falls ein Server mit sv_maxupdaterate 30 läuft, ist hierbei cl_updaterate noch um weitere 10% niedriger, da jener Wert manchmal überschritten wird (werden muss) und dennoch nicht das serverseitige Maximum überschreiten sollte, was ansonsten zu Synchronisierungsstörungen und somit zu spürbaren Verzögerungen führen kann. Desweiteren sind diese Netsettings als Notfallsettings zu verwenden, sollten höhere Einstellungen allesamt zu keinem guten Spielgefühl fühlen.
Interpolation CS:SOURCE
CS:Source ist die erste Version von Counter-Strike, in welcher das Prinzip der Interpolation und Extrapolation beinahe mathematisch korrekt angewandt wird. Diese beiden mathematischen Methoden sind in der Lage, aus den Bewegungsdaten eines Spielers zukünftige Bewegungen vorherzuberechnen und die Animationen durch Zwischenschrittberechnungen flüssig darzustellen, selbst wenn die Menge der vorhandenen Daten nur so gering ist, dass die Animation ohne jene Zwischenschrittberechnung (Interpolation) extrem ruckartig wäre. Wenn man eine Bewegung extrapoliert, kann man innerhalb gewisser Grenzen sagen, wo sich jemand in einer bestimmten Zeit höchstwahrscheinlich befinden wird. Im Sinne von Multiplayerspielen hat die Extrapolation den Sinn, dass die von Pings repräsentierten Verzögerungen mathematisch ausgeglichen werden können - dauert es beispielsweise 56 Millisekunden, bis man die Bewegung eines Spielers sieht, so wäre das, was man sieht, ohne Extrapolation immer 56 Millisekunden alt. Nun müssen also 56 Millisekunden extrapoliert werden, wodurch die durch das Internet entstandene Verzögerung mathematisch ausgeglichen wird. (Anmerkung: hierbei handelt es sich NICHT um die so genannte Lag-Compensation, denn diese ist für die umgedrehte Datenrichtung zuständig, also dass ein Gameserver die Verzögerung ausgleichen kann) Diese Vorherberechnung, die Extrapolation wird, je weiter man in Zukunft \"se |
