Clientseitiger NETCODE-FIX!? Paketverlust als Ursache + how to fix

risingSilence

Komplett-PC-Käufer(in)
Hi Leute,
hab ne sehr interessante Entdeckung gemacht!
Der Netcode von dem Spiel brachte mich zur absoluten Weißglut. Sterben und dann erst sehen, wie der Gegner um die Wand kommt. Sterben und dann erst den Gegner überhaupt mal schießen hören. Einfach haarsträubende, scheinbar sekundenlange Asynchronitäten und das permanent und auf jedem Server. Also hab ich vor Verzweiflung das googlen angefangen und bin auf das Thema Paketverlust gestoßen.
Also folgendes Tutorial gleich mal angewandt:

MTU Limit - Test and change your connection's MTU limit - Windows 7 Help Forums

Erste Tests zeigen: Oh! 100% Paketverlust! also MTU angepasst, bis ich irgendwann beim Wert 1480 gelandet bin statt Standard-1500. Kein Paketverlust mehr.

Mein Ping ingame ist gesunken von 30-35 auf 20-25. Soweit so gut. Ob ich jetzt mit 20er Ping spiel oder mit 35er... Dem Ping nach müsste beides gut spielbar sein.
Naja die Tage vergingen und irgendwie war ich seit dieser Änderung plötzlich wieder so gut wie in BF3. Ich traute meinen Augen kaum... Gegner im Lauf erwischt und dieser stoppt erst ab und schießt dann - und fällt um weil ich auf ihn feuer. KEIN Tod mehr hinter Wänden, selbst bei vielen riskanten Firefights auf Locker. Und generell sind Firefights wieder einschätzbar - man kann in Deckung gehen wenn man die ersten Treffer kassiert und der Gegner feuert einfach live und nicht bevor er erst herschaut und und und.... das spiel ist einfach wieder synchron!!!
Unglaublich, wie ich seit dem abgeh. Es ist doch nicht alle PROS geworden, letztendlich wars doch nur mein Netzwerk, das dieses Spiel so komplett gaga gemacht hat.
Ich glaube daher kommt es auch, dass manche Leute nicht verstehen können, wie andere Leute über den Netcode derart heftig herziehen! Vielleicht haben die einfach kein Packet Loss!!!
Doch alle, die diese Asynchronitäten haben, haben keinen Grund das Spiel zu spielen. Nach diesem FIX sollte es so funktionieren wie bei mir und bei denen, die kein Packet Loss haben - ein synchrones Spielerlebnis ist ermöglicht!
ZUMINDEST bei mir hat es unheimlich viel geholfen. Mein PC ist mit dem Router direkt verbunden und ich besitze WIN 8.1 x64 und VDSL 50 (42 kommen an). Meine MTU ist 1480 und ich spiele Battlefield 4. Live! Synchron! Und endlich wieder erfolgreich! PROBIERT ES AUS!!!!!

Hier noch mein kurzes Video, wo ich das ganze noch mal kurz thematisiere. Wobei es nicht mehr sooo sehenswert ist, wenn ihr den Text gerade schon gelesen habt. :)

https://www.youtube.com/watch?v=NSDIPOuj9EY

BITTE lasst Feedback da, wie bei euch die Wirkung ist, und lasst euch mit dem Testen genau so viel Zeit wie ich, um Placebo-Effekte ausschließen zu können! (ca 5 Std. Spielzeit bei mir, ich empfehle mindestens 2)
 
Ich bin einer davon der das Gejammer mit dem netcode net nachvollziehen kann. Meine Erfahrung ist, dass Kabelkunden wie ich, eh weniger betroffen sind. Und wie du sagst: Es hilft halt nur clientseitig - ist aber vielleicht ein Schritt in die richtige Richtung.
Freut mich für dich wenns geklappt hat :daumen:
 
Hatte erst 75% package lost und dann 100%.
Durch deinen Trick hab ich jetzt 0% Package lost, jetzt werd' ich direkt mal BF4 testen.


P.S.: Hast ein Abo und Like mehr :daumen:
 
Ich werds auch mal probieren, danke für dein Video.
Dich hat es in den Wahnsinn getrieben, ich bin fast Amok gelaufen! :ugly:

Bei mir hab ich nichts verändert und es schaut so aus:

C:\Windows\system32>ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.100] mit 1472 Bytes Daten:
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=32ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=32ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=31ms TTL=45

Ping-Statistik für 173.194.70.100:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 31ms, Maximum = 34ms, Mittelwert = 32ms

C:\Windows\system32>ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.100] mit 1472 Bytes Daten:
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45

Ping-Statistik für 173.194.70.100:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 33ms, Maximum = 34ms, Mittelwert = 33ms

C:\Windows\system32>ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.100] mit 1472 Bytes Daten:
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=32ms TTL=45

Ping-Statistik für 173.194.70.100:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 32ms, Maximum = 34ms, Mittelwert = 33ms

C:\Windows\system32>ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.100] mit 1472 Bytes Daten:
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=35ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=32ms TTL=45

Ping-Statistik für 173.194.70.100:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 32ms, Maximum = 35ms, Mittelwert = 33ms

C:\Windows\system32>ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.100] mit 1472 Bytes Daten:
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=34ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=30ms TTL=45
Antwort von 173.194.70.100: Bytes=64 (gesendet 1472) Zeit=33ms TTL=45

Ping-Statistik für 173.194.70.100:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 30ms, Maximum = 34ms, Mittelwert = 32ms

C:\Windows\system32>

1500 1 4919998666 144186549 Ethernet

Müsste jetzt 1500 in 1472 abändern korrekt, weil bei ping google.com -f -l 1500 bekomme ich Packetverlust und bei ping google.com -f -l 1472 nicht.

Habe jetzt
netsh interface ipv4 set subinterface "Ethernet" mtu=1472 store=persistent
eigegeben und das ist bei raus gekommen:
1472 1 4920194882 144351204 Ethernet

Hab ich soweit richtig verstanden? Weil wenn ich jetzt ping google.com -f -l 1472 eingebe, bekomme ich Packetverlust. Oo

------ --------------- --------- --------- -------------
1472 1 1671594 238750 Ethernet
4294967295 1 0 22309 Loopback Pseudo-Interface 1
1500 5 0 0 Bluetooth-Netzwerkverbindung


C:\Windows\system32> ping google.com -f -l 1472

Ping wird ausgeführt für google.com [173.194.70.101] mit 1472 Bytes Daten:
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.
Paket müsste fragmentiert werden, DF-Flag ist jedoch gesetzt.

Ping-Statistik für 173.194.70.101:
Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
(100% Verlust),
 
Zuletzt bearbeitet:
Also nochmal meine Vorgehensweise:

1. "netsh interface ipv4 show subinterfaces" eigegeben
Ergebnis war "1500 1 33939553 1571883 Ethernet", sprich 1500

2. "ping google.com -f -l 1500" eingegeben
Ergebnis war 100% Packetverlust

3. "ping google.com -f -l 1472" eigegeben
Ergebnis kein Packetverlust mehr

4. "netsh interface ipv4 set subinterface "Ethernet" mtu=1472 store=persistent" eingegeben
Ergebnis danach "1472 1 33939553 1571883 Ethernet", sprich 1472

5. "ping google.com -f -l 1472" eigegeben
Ergebnis 100% Packetverlust obwohl es zuvor ging

WTF?

Mit "ping google.com -f" habe ich generell kein Packetverlust, weder bei 1500 noch bei 1472.

OS ist Win 8.1 x64
 
Zuletzt bearbeitet:
Also nochmal meine Vorgehensweise:

1. "netsh interface ipv4 show subinterfaces" eigegeben
Ergebnis war "1500 1 33939553 1571883 Ethernet", sprich 1500

2. "ping google.com -f -l 1500" eingegeben
Ergebnis war 100% Packetverlust

3. "ping google.com -f -l 1472" eigegeben
Ergebnis kein Packetverlust mehr

4. "netsh interface ipv4 set subinterface "Ethernet" mtu=1472 store=persistent" eingegeben
Ergebnis danach "1472 1 33939553 1571883 Ethernet", sprich 1472

5. "ping google.com -f -l 1472" eigegeben
Ergebnis 100% Packetverlust obwohl es zuvor ging

WTF?

Mit "ping google.com -f" habe ich generell kein Packetverlust, weder bei 1500 noch bei 1472.

OS ist Win 8.1 x64

Du muß noch 28 zu dem Wert den du beim Pingen verwendest dazuzählen. ;)
Wenn du also ping google.com -f -l 1472 eingibst dann testest du eigentlich mit einer MTU von 1472 + 28 = 1500
Das ist bei dir aber eh schon eingestellt

Bei ping google.com -f -l 1500 wäre das eine MTU von 1528


Und hast du den Rechner nachdem du die MTU umgestellt hast - damit das ping google.com -f auch richtig funktioniert - wohl auch neu gestartet?
 
Zuletzt bearbeitet:
Ich konnte meinen Wert auf 1492 reduzieren ( Standard 1500 ), mal schauen, ob sich jetzt grossartig was ändert :)

Noch eine Frage.. ich bin mit 1462 gestartet und hatte 0 % loss. Dann soll man ja immer einen Wert höher gehen, bis wieder Packet loss vorhanden ist. Bei mir war der Wert 1464, bei **65 waren wieder loss vorhanden. Muss ich jetzt von 1462 + 28 addieren oder von 1464 ? Bin jetzt von 1464 ausgegangen.

Ansonsten sehr hilfreicher Beitrag :daumen: und sofern ich wirklich veränderungen merke, werde ich Rückmeldung geben.
 
Ja ich habe neugestartet, so stand es ja auch im Sevenforum.

Wie gehabt

1500 1 33939553 1571883 Ethernet
ping google.com -f

= kein Packeverlust

1472 1 33939553 1571883 Ethernet
ping google.com -f

= ebenfalls kein Packetverlust

Netcode Probleme hab ich trotzdem!

Mtupath spuckt folgendes aus:

C:\Users\XXX\Desktop\Netcode>mtupath -4 google.de

MTU path scan to google.de (173.194.70.94), ttl=64, limit=48
# 16 processing - best MSS 1444 (estimated MTU 1472) [pPPPPpPppPpPPPpp]
# 01 nearest minimum MTU on local interface

#1 MSS IN RANGE 1 <== 1443 ==> 1444
#2 MSS EXCEEDED 1445 <== 14939 ==> 16384

Das heißt jetzt was?
 
Zuletzt bearbeitet:
  • Like
Reaktionen: uka
Also ich habe hier auch nirgens Paketverlust und dennoch bin ich teilweise schon 3 Treppen weiter wenn ich um 4 Ecken getötet werde.

Lächerlich :ugly:
 
Bei mir kommt immer "Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch.

netsh interface ipv4 show subinterfaces

musst schauen, wie dein Netzwerk heisst und demensprechend dort --> netsh interface ipv4 set subinterface "User Network" mtu=1490 store=persistent ; eingeben.
 
Was ist jetzt korrekt?

1472 1 5659287 949358 Ethernet
1500 1 5659287 949358 Ethernet

Im Router ist noch folgendes hinterlegt:

MTU Size (in bytes): 1500 (The default is 1500, do not change unless necessary.)

Im CMD wird mir folgendes angezeigt (hab ich von 1500 in 1472 abgeändert):

1472 1 5659287 949358 Ethernet
 
Zurück