[Biete] Tutorial für direktere Hitabfragen in FPS Games für PC

supersonik

Zero Hero
Otaku Veteran
Hallo liebe Community,

ihr seid FPS Spieler und habt euch schon öfter über das nicht treffen der Gegner genervt, obwohl ihr mit dem Fadenkreuz drauf wart?

Das könnt ihr von euer Seite (Client Side) ein wenig verbessern!
Wie? Das werde ich euch in diesem Tutorial zeigen und erklären.

Angefangen erstmal mit der öden Theorie von Netzwerktechnik, damit ihr auch versteht hinterher was ihr getan habt.

Jegliche Kommunikation im LAN= Local Area Network (Standort gebunden beispiel: Heimnetzwerk ist ein LAN)
oder
WAN= Wide Area Network (Standort ungebunden beispiel: Internet das größte bekannte WAN),

wird durch Pakete in verschiedener Form abgehalten. Diese Pakete benutzen verschiedene, sogenannte Protokolle. Für den Web Surfing Bereich ist größtenteils das TCP Protokoll im Einsatz was, vereinfacht gesagt eine Prüfung mit sich mitbringt. Diese schaut nach ob alle gesendeten Pakete die, z.B. für den Aufbau der Internetseite xy benötigt werden, auch alle beim Empfänger angekommen sind. Geht ein Teil verloren(sogenannter Paket-Verlust) schickt es diese erneut um eine Fehlerfreie Darstellung zu bieten. Denn wer von euch würde schon wollen dass seine/ihre Lieblings Seite Fehlerhaft oder gar nicht mehr verständlich angezeigt wird? Diese Prüfung kostet allerdings erhebliche mehr Latenz und macht somit TCP unbrauchbar für Online Gaming.

Nämlich bei fast alle Online Spiele die auf dem Markt sind, kommuniziert der Server mit Euch über UDP Pakete. Diese enthalten keine Prüf-Funktion und sind allgemein eher minimalistisch gehalten. Mit ihnen sind geringe Latenzen möglich, jedoch wenn ein Paket verloren geht fehlt dieses einfach schlichtweg. Paket-Verlust in Online Spielen kann je nach schwere, von kleinen Rucklern bis hin zu kompletten Zeitüberschreitungen führen die euch dann egal in welchem Genre nur negatives einhalsen.

Ich erkläre euch nun wie ihr Paket-Verlust (Client-Side) vermeiden könnt, in dem ihr die maximale Übertragungseinheit (MTU) an eure Verbindung anpasst. Standard ist der MTU nämlich von Windows für alle Verbindungen auf 1500 Bytes eingestellt, da dieses dem Ethernet Standard entspricht, aber ein ganz bisschen von dem DSL Standard (1492 Bytes) abweicht kann das zu Paket-Verlust führen!
(Dies gilt nur für DSL Internet Kunden, alle anderen bitte extra Fragen vorher hier bevor sie weitermachen wollen, ich werde euch dann weiterhelfen oder ggf. bei einer größeren Masse die Werte nachtragen)

Schritt 1:

CMD als Admin ausführen und durch folgenden Befehl eure Schnittstelle zum Internet identifizieren "netsh interface ipv4 show subinterfaces"

nun werden euch alle Schnittstellen angezeigt die ihr habt und ganz vorne auch der vergebene MTU.
Wenn dieser nicht 1500 ist bitte nicht weitermachen sondern herrausfinden wer das umgestellt hat und warum!

Schritt 2:

Folgenden Befehl in die noch geöffnete CMD eingeben und mit enter bestätigen "netsh interface ipv4 set subinterface "Eure Schnittstelle" mtu=1492 store=persistent"

Die Eingabe erfolgt ohne " und Eure Schnittstelle wird mit beispielsweise Ethernet oder LAN ausgefüllt. bei mir sieht das so aus (netsh interface ipv4 set subinterface Ethernet mtu=1492 store=persistent)

Schritt 3:

Mit dem Befehl aus Schritt 1 "netsh interface ipv4 show subinterfaces" nochmal überprüfen ob der Wert richtig gesetzt wurde. Unter MTU nachlesen.

Schritt 4:

PC neustarten damit die Änderungen vollständig übernommen werden.

Viel Spaß beim Zocken mit genaueren Hitabfragen und weniger Timeouts.


(Quelle: ehemaliges Battlefield Forum + Gedankengut + Wikipedia)
 

Lia

Don't eat the help! ツ
Otaku Veteran
ihr seid FPS Spieler und habt euch schon öfter über das nicht treffen der Gegner genervt, obwohl ihr mit dem Fadenkreuz drauf wart?

Das könnt ihr von euer Seite (Client Side) ein wenig verbessern!
Wie? Das werde ich euch in diesem Tutorial zeigen und erklären.
Ich verstehe den Zusammenhang dazu nicht:
Ich erkläre euch nun wie ihr Paket-Verlust (Client-Side) vermeiden könnt, in dem ihr die maximale Übertragungseinheit (MTU) an eure Verbindung anpasst.
Es geht offenbar um Paketverlust, der zu laggs führt. Die MTU hat meines Wissens nichts damit zu tun.
Wie du schon richtig geschrieben hast, verwendet das UDP-Protokoll keine Redundanz, wodurch Paketverluste auftreten können. Dennoch kann ein Client UDP-Pakete mit einem Server austauschen, die redundante Daten enthalten. (das ist aber nicht das Problem)
Du gehst scheinbar davon aus, dass eine MTU von 1500 zu Paketverlusten führen kann. Wenn die MTU tatsächlich zu groß wäre, dann würdest du den Server nichtmal erreichen.
Wäre ein Paket aufgrund der MTU tatsächlich zu groß, würde dieses Paket im Normalfall abgelehnt werden. Dadurch würde der Sender die Antwort erhalten, dass das Paket zu groß war. (Das wäre das erste Paket, das verloren gehen könnte)
Dieses Problem hättest du jedoch nur, wenn eine Framentierung durchgeführt wird und der Empfänger Datenpakete mit dem More-Flag ablehnt. Dadurch teilt der Empfänger (das sollte bereits beim Router passiert) dem Sende aber mit, dass das Paket zu groß war.
Demnach kann es höchstens passieren, dass bereits an der Stelle durch sehr außergewöhnliche Szenarien, wie eine sehr falsch konfigurierter Firewall, das Feedback zur Paketgröße nicht ankommt und die Pakete immer wieder gesendet, aber abgelehnt werden.
Die MTU kann eine Kommunikation nur hinsichtlich ihrer Übertragunsrate beeinflussen. Für die Situation MTU=1500 wäre der worst case, dass die Fragmentierung tatsächlich durchgeführt und akzeptiert wird. Da es sich demnach um 2 Datenpakete handelt, kommt beim zweiten Paket ein weiterer Header hinzu, der das ursprüngliche Paket nochmal um seine eigene Größe aufbläht.
In diesem Fall könnte man die MTU tatsächlich verringern. Auf der Ebene würde ich allerdings niemals an meiner Netzwerk-Kommunikation rumspielen.
Ich bin außerdem der Meinung, dass ein halbwegs vernünftiger... jeder Router die Größe der Datenpakete ohnehin anpasst. Demnach kommuniziert nur der Router mit deinem Rechner mit einer MTU von 1500.
... gutti, das wäre mein Beitrag zu dem Thema ^^

Was anderes: muss man einen Windows-Rechner wirklich neu starten, wenn man die MTU geändert hat? :huh:
 

supersonik

Zero Hero
Otaku Veteran
Naja bei Shootern kommt es neben der serverseitigen Tickrate, auch darauf an das man ohne Paketverlust spielt und nicht plötzlich durch eine hohe Datenrate aufeinmal Paketverlust bekommt und somit laggt oder gar einen timeout bekommt. außerdem ist die punktgenaue abfrage sehr sehr entscheidend.

Beispiel CSGO

Der Server bietet eine Tickrate von 128 dazu ermächte ich meinem csgo client via config dazu 128000 bytes als maximale daten rate festzulegen. Da haben Erfahrungsberichte nicht nur im Bekannten Kreis gezeigt, das diese Minderung der MTU zumindest bei CS Spielern für einen Reibungslosen Verlauf notwendig/ empfohlen ist.

Und die DF Flag wird gesetzt wenn du mit standard 1500bytes paket größe internet adresse xy anpingst "ping google.com -f -l 1500". teste es mal aus.

Wird auch durch das ingame Tool Netgraph bestätigt das es zwischen 1-5% loss gibt.

Natürlich ist das nur die MTU zwischen Endgerät und Router und wenn der es noch nicht Kann dann aber der ISP hat es auf 1492. Das weiß ich deswegen war auch von vornerein von client side die rede. hätte ich vllt noch genauer erläutern müssen.

DSL=1492 bytes
LTE=1362/1360 bytes je nach anbieter kann das aber auch noch vareieren
ISDN=576
FibreChannel/Glasfaser= theoretisch unbegrenzt groß

Man kann letztendlich nicht seine WAN MTU selbststädig verändern das wollte ich auch nie zum ausdruck bringen. Jedoch ist diese Anpassung kein reiner Placebo Effekt wie andere Einstellungen bei Shootern.


Jein Windows übernimmt es Teilweise schon direkt nach der Eingabe, die MTU allerdings müsste man dann erst mit Verbindung Trennen bzw. Stecker ziehen und wieder rein stecken den Vorgang forcieren.
Außerdem wurde in allen Quellen, die ich mir dazu angeschaut habe dazu geraten einen Neustart zu tätigen.
 

Lia

Don't eat the help! ツ
Otaku Veteran
außerdem ist die punktgenaue abfrage sehr sehr entscheidend.
Versteh' ich nicht.

Da haben Erfahrungsberichte nicht nur im Bekannten Kreis gezeigt, das diese Minderung der MTU zumindest bei CS Spielern für einen Reibungslosen Verlauf notwendig/ empfohlen ist.
Das ist doch aber keine philosophische Frage, immerhin sind OSI & co keinen Blackboxen.^^

Und die DF Flag wird gesetzt wenn du mit standard 1500bytes paket größe internet adresse xy anpingst "ping google.com -f -l 1500". teste es mal aus.
Ja, muss ja so sein, wenn du einen Rechner hinter deinem Router anpingst und die Paketgröße auf 1500 festlegst. :)
Im Normalfall werden die Pakete aber nicht mit einer Größe von 1500 gesendet:
Bildschirmfoto von »2015-09-11 00:31:42«.png
und wie ich bereits vermutet habe, werden diese Datenpakete abgelehnt. (Puh! Dachte schon, ich hab Unsinn geschrieben :XD:)
 

supersonik

Zero Hero
Otaku Veteran
Naja in Counter Strike kommt eine sehr genaue Abfrage zum Einsatz, unter den 3 Großen Reihen CS | BF | CoD ist es sogar die genauste. Wie es über den Tellerrand hinweg aussieht weiß ich nicht genau, bin ja immer hin kein Entwickler oder so :D

Das heißt man Fraggt nur, wenn auch wirklich alles Genau passt in der Berechnung.
Sprich, man darf nicht zu viel Spread vom Laufen/Springen noch dabei haben, deine Einstellungen am Spielen müssen stimmen(64 Tick optimiert wenn Server 64 Tick und 128 Tick optimiert wenn der Server 128 Tick ist), die Game Server dürfen nicht zu überlastet sein(Matchmaking Server von Valve sind leider oftmals nicht optimal für das beste Spiel Erlebnis. Besser eigene gemietete Server oder Liga Server benutzen falls man dort spielt/spielen darf), das Aiming muss bestenfalls Kopf sein aber halt auf dem Gegner Modell.
So gehen wir mal davon aus alle ebend genannten Sachen sind optimal erfüllt, dann heißt es zumindest bei CS & BF, für CoD kann ich das nicht unbedingt sagen, das es trotzdem nicht immer hitted obwohl optisch alle Voraussetzungen erfüllt sind fällt der Gegner nicht um oder der hit kommt ein wenig indirekt an, quasi wie ein nicht Latenzberechnete Verzögerung.

Diese geht hervor durch den minimalen Paket-Verlust.

Natürlich sind Theorien und überlieferte Modelle wie z.B. das OSI wahr und zu 99,9999% auch immer zutreffend, aber in diesem Falle ist es etwas spezielles. Was den Theorien widerspricht .

Wodurch auch immer diese Unregelmäßigkeit zustade kommt, Ich weiß nicht ob es die Unfähigkeit der Entwickler ist es so zu regeln das kein Verlust entsteht und alles Direkt bleibt oder ob es ein anderes Problem gibt.

Außerdem hast du es unter Linux getestet. Es geht hier jedoch um Windows Rechner/Laptops etc...

Das kann man nicht verallgemeinern, auf Straegie Spiele oder andere Anwendungen die auch via udp laufen.

Die Games sind da ein anderer Schlag, und ohne Witz ich bin nicht hier um jemanden etwas falsches Vorzugaukeln, ich will lediglich meine Erfahrungen teilen.

Ich hab ein paar Leuten das schon erklärt und sie haben das eingestellt und bei allen die DSL (egal ob DSL/ADSL/ADSL2/VDSL) hatten war ein besseres Ergebnis zu verzeichnen.

Natürlich, stimmen deine Aussagen nach den allgemein geltenden Gesetzen und Regeln bzw. Theorien der Netzwerktechnik aber Spiele Engines scheinen da noch ein extra Fall zu sein.

Hier ein anderer Guide von einem anderen CS Community User, der sogar eine eigene Page hat und dort diesen Beitrag veröffentlich hat. http://www.dcgaming.org/tcp-optimization-for-lower-pings/

Desweiteren ist der Ursprung meines Interesses an diesem Thema, damals BF4 gewesen da dort Quasi nichts gefraggt wurde von mir und ich mich im internet schlau machte was der grund dafür ist, wie es dazu kommt, wer das Problem lösen kann und was man selber dafür eventuell noch tun kann. Und das war halt ein Video was ich niht mehr wieder finde schon so 2 Jahre fast her.

Allerdings bin ich mir grad nicht ganz sicher ob ich dich richtig verstanden habe :/
 

Zero

Chief 0perating 0fficer
Teammitglied
Admin
imho:

also ich habe mir mal den Spaß gemacht und das auf den ping losgelassen.
1464 ist schon mal kaputt (also das MTU mit 1492) da ändert sich bei mir namlich nichts und er heult rum, dass er das immer noch fragmentieren will

bei mir schafft er es mit 1412
Das ist die methode, die er Mensch in deinem link vorgeschlagen hat.

Es hat allerdings meinen ping nicht verbessert.
Was mich dann aber dazu führt zu fragen, wenn es nicht für den Ping inst, was dann. Mehr Datendurchsatz durch nicht fragmentieren?
Dann allerdings sind wir nicht im TCP-Bereich, wo jedes Paket ein ACK bekommt, sondern im UDP. Geht das UDP-Package verloren, ist es halt weg. Shit happens (deswegen gibt es oft VPNs, die doch auf TCP gehen, weil dort das paket eben noch mal geschickt wird, wenn keine Antwort kommt - macht es stabiler, aber auch etwas langsamer)
und mein router das jetzt splittet oder nicht, sollte an sich bei einer halbwegs ordentlichen Verbindung rel. egal sein. wie schon gesagt, hat das mit paketverlusten nur dann was zu tun, wenn die Verbindung kacke ist und die pakete zwischendrin verloren gehen - der server also nicht weiß, was du tun willst.
 

supersonik

Zero Hero
Otaku Veteran
Also zusammenfassend liege ich in dem Punkt falsch, dadurch Paketverlust zu vermeiden, da gar kein Paketverlust auftritt richtig ?
Auch tritt keine Ping Verbesserung auf.

Aus der Unterhaltung mit euch beiden schließe ich, das ich mich Grundlegend geirrt habe und von falschen Gegebenheiten ausging und den Quellen/Artikeln zu blind geglaubt habe.
Das außerdem kein Paket in voller 1500 bytes Größe so schnell verwendet wird und das ja auch nur in der Strecke vom Client zum Router. Dahinter ist es ja eh Anbieter gesteuert.
Unterm Strich war das ganze dann wohl doch nur ein Placebo-Effekt.

Vielen Dank für die Diskussion und die Belehrung ihr beiden.
 
Zuletzt bearbeitet:

Lia

Don't eat the help! ツ
Otaku Veteran
Naja in Counter Strike kommt eine sehr genaue Abfrage zum Einsatz, unter den 3 Großen Reihen CS | BF | CoD ist es sogar die genauste.
...
das Aiming muss bestenfalls Kopf sein aber halt auf dem Gegner Modell.
Achso, die "punktgenaue Abfrage" bezog sich auf die Kollisionsabfrage. ^^
Die wird aber vom Server berechnet bzw. validiert. Das muss ja auch so sein, sonst könntest du ja Spieler mit laggs einfach aus dem Verkehr ziehen. ^^
Andersrum, könntest du selbst ein kleines Tool verwenden, was dir kurz die Verbindung blockiert, damit du in Ruhe zielen kannst. ^^
... oder meintest du damit was anderes?

Sprich, man darf nicht zu viel Spread vom Laufen/Springen noch dabei haben
Bei einem Schuss muss nur ein Vektor übertragen werden. Der besteht auch nur aus 3 Zahlen und ist vielleicht 12 Byte groß. Die 12 Byte werden einfach mit in das Paket gesteckt, das du ohnehin in regelmäßigen Abständen zum Server sendest. Da hast du dann sowas dabei wie:
  • Position : 8-16 Byte
  • Blickrichtung : 12 Byte
  • ist er gesprungen? : 1 Bit
  • optional Schussvektor : 12 Byte
  • Waffe : max 1 Byte
  • Waffenwechsel: max 1 Byte
  • Pose (sowas wie: hockt der Spieler etc.) kann durch eine Zahl dargestellt werde, die der Server der Pose zuordnet : max 1 Byte
Keine Ahnung ob das hinkommt, vielleicht hab ich auch paar Sachen vergessen. Jedenfalls bin ich ja der Meinung, dass ein Client in viel kürzeren Abständen Pakete senden muss. Würde er erst warten bis er die 1500 Byte zusammen hat, würde ja jeder durch die Gegend springen^^

die Game Server dürfen nicht zu überlastet sein
Meinst du damit zb durch die Berechnung der Kollisionserkennung? Das ist ganz einfach auf der Serverseite. Der kann die Modelle ganz abstrakt betrachten, zB durch Punkte (Position, Kopf, Füße,Kniee, Becken,Hände,Ellenbogen, Schulter). Dadurch verwendet der Server nur ein Strichmännchen, dass er je nach Körperbereich um einen bestimmten Radius erweitert. Durchgeführt muss diese Berechnung ohnehin. Es denke es stellt sich mehr die Frage wie der Server mit Verzögerungen umgeht. Er könnte zum Beispiel einfach eine gewisse Zeit warten und dann einfach die letzte bekannte Position des Spielers verwenden. Er könnt auch warten bis das nächste Paket kommt und dann anhand der beiden Zeitstempel die Position zwischen den beiden Punkten berechnen zum Zeitpunkt als auf ihn geschossen wurde. Vielleicht werden auch keine Zeitstempel verwendet, sondern der Zeitpunkt an dem das Paket eingetroffen ist. Wie auch immer, da gibt es unzählige Möglichkeiten.

Zu dem Thema kommt mir grad noch dieses Video in den Sinn.^^

Außerdem hast du es unter Linux getestet. Es geht hier jedoch um Windows Rechner/Laptops etc...
Macht keinen Unterschied, der Router bekommt nur ein Paket. :)

Das kann man nicht verallgemeinern, auf Straegie Spiele oder andere Anwendungen die auch via udp laufen.
Kommt drauf an wie weit du das verallgemeinern willst^^ Ich lehne mich mal so weit aus dem Fenster zu behaupten, dass Aktionen immer an den Server geschickt werden und dieser diese dann berechnet udn das Ergebnis an die Clients schickt.
Der Client muss aber nicht zwingend auf eine Antwort warten um zB einen Schuss schonmal zu animieren... der Spieler sieht ja dann ob sein Ziel dann umkippt^^

und ohne Witz ich bin nicht hier um jemanden etwas falsches Vorzugaukeln, ich will lediglich meine Erfahrungen teilen.
Weiß ich doch und find' ich gut :)

Hier ein anderer Guide von einem anderen CS Community User, der sogar eine eigene Page hat und dort diesen Beitrag veröffentlich hat. http://www.dcgaming.org/tcp-optimization-for-lower-pings/
Interessant finde ich die Kommentare darunter ^^

Also zusammenfassend liege ich in dem Punkt falsch, dadurch Paketverlust zu vermeiden, da gar kein Paketverlust auftritt richtig ?
Auch tritt keine Ping Verbesserung auf.

Aus der Unterhaltung mit euch beiden schließe ich, das ich mich Grundlegend geirrt habe und von falschen Gegebenheiten ausging und den Quellen/Artikeln zu blind geglaubt habe.
Das kann man so nicht sagen. Ich denke eher, dass das Thema (MTU) nicht zum beschriebenen Szenario passt. Angenommen ein Paket der Größe 1500 soll tatsächlich sofort rausgeschickt werden und es wird demnach fragmentiert, dann hast du damit einen Header mehr. Da sich dadurch die Datenmenge erhöht, hättest du damit theoretisch schon einen höheren Ping.
Die Frage ist nur ob du das Bischen überhaupt merkst.^^ Naja und die Praxis haben wir ja bereits breit genug getreten. :XD:

/delete on request
:nani: Das ist doch ein super Thema. Du hast dich umfangreich informiert und das hat man auch gemerkt.
Außerdem haben wir viel wertvolles Wissen ausgetauscht, wäre doch ein Verbrechen das zu löschen. ^^
Schreib weiter solche Sachen!
:banzai:
 
Zuletzt bearbeitet:

supersonik

Zero Hero
Otaku Veteran
... oder meintest du damit was anderes?
Ne genau das meinte ich.

Keine Ahnung ob das hinkommt, vielleicht hab ich auch paar Sachen vergessen.
Sick...ne das ist glaube ich schon ziemlich genau. Ich weiß definitiv nichts anderes, ich wusste nicht mal das.

Meinst du damit zb durch die Berechnung der Kollisionserkennung?
Jein, viel mehr war die Aussage getroffen auf die Gesamt Hardware Auslastung. Beispiel Steam hat seine Roots bis zur Oberkannte voll, hat man jedenfalls das Gefühl, und dadurch hat man dann teilweise schlechte Kollisionserkennung/Kollisionsabfrage , macht sich durch schlechtere Ping Zeiten und FPS Schwankungen meist bei csgo bemerkbar. Aber die wollen natürlich aus wirtschaftlichen Gründen möglichst viel aus den Roots raus holen und gut geld verdienen :( was halt schade ist für die Spieler manchmal.

Macht keinen Unterschied, der Router bekommt nur ein Paket.
Das ist gut zu wissen dass so etwas, Betriebssystem übergreifend ist und das System keine Rolle dabei spielt. :DDD

"Das kann man nicht verallgemeinern, auf Straegie Spiele oder andere Anwendungen die auch via udp laufen." <---das streichen wir ausm Kontext ..

Interessant finde ich die Kommentare darunter ^^
Die Kommentare ganz unten hatte ich gar nicht bemerkt das sowas ist..völlig übersehen.

Das kann man so nicht sagen. Ich denke eher, dass das Thema (MTU) nicht zum beschriebenen Szenario passt.
Ne genau, da kann man nur darauf hoffen das valve etwas mit der Kollisionserkennung verbessert oder die Serverlast mindern kann.



Das ist doch ein super Thema. Du hast dich umfangreich informiert und das hat man auch gemerkt.
Außerdem haben wir viel wertvolles Wissen ausgetauscht, wäre doch ein Verbrechen das zu löschen. ^^
Schreib weiter solche Sachen!
Stimmt schon, nur war es mir zuerst so peinlich das ich so fatal daneben gegriffen hatte :'D
Hat auf jedenfall Spaß gemacht und mir einfach Klarheit in das Thema gebracht. Sodass ich mehr Wissen als vorher habe und auch über Thema, besser bescheid weiß. :)
 

Zero

Chief 0perating 0fficer
Teammitglied
Admin
Also zusammenfassend liege ich in dem Punkt falsch, dadurch Paketverlust zu vermeiden, da gar kein Paketverlust auftritt richtig ?
naja, es gibt nur ein weiß/schwarz hier.
d.h. entweder kommt das UDP-Paket durch, oder eben nicht. Das ist der Nachteil, wenn man darüber Daten austauscht, die unbedingt ankommen müssten - dafür ist es aber auch schneller und einfacher zu implementieren (deshalb wohl auch in Spielen beliebter)

naja, für solche Diskussionen sind doch Foren da, von daher ist es nicht schlimm und eher fördernd :)
 
Oben