Netzwerk-Glättungsfaktor

[Sabr]

Hallo zusammen,
kann mir einer erklären wozu die neue Option Netzwerk-Glättungsfaktor gut ist bzw. wie man es perfekt einstellt?



gruss

 

[joel]

Grundlagen der Netzwerktechnik,

Für jede Verbindung verwaltet TCP die Variable RTT (Round-Trip-Time). Das ist die momentan beste Schätzung der
Rundreisezeit zum fraglichen Ziel. Wird ein Segment gesendet, startet ein Timer. Er überwacht, wie lange die Bestätigung
braucht, und löst bei Bedarf eine Neuübertragung aus. Kommt die Bestätigung zurück, bevor der Timer abläuft,
mißt TCP, wie lange die Bestätigung dauerte, z.B. M. Dann wird RTT nach der Formel
RTT = aRTT + (1 - a)M
aktualisiert. Dabei ist a ein Glättungsfaktor, der bestimmt, wieviel Gewicht dem alten Wert beigemessen wird. Ein
typischer Wert ist a = 7/8.
Auch bei einem guten RTT-Wert ist die Auswahl eines geeigneten Timeouts für Neuübertragungen keine leichte Aufgabe.
Zur Anpassung an die Varianz der Übermittlungszeiten wird die geglättete Variable
D=aD + (1 - a)|RTT - M|
als Abweichung gegeben, wobei a nicht unbedingt der gleiche Wert sein muß, der zum Glätten von RTT benutzt
wurde. D ist zwar nicht genau das gleiche wie die Standardabweichung, aber gut genug. Die meisten TCP-Implementierungen
benutzten heute diesen Algorithmus und setzen das Timeout-Intervall auf
Timeout = RTT + 4 x D
Die Auswahl von Faktor 4 ist mehr oder weniger arbitär, hat aber zwei Vorteile. Erstens sind Multiplikationen um 4
ohne Verschiebungen möglich. Zweitens werden unnötige Timeouts und Neuübertragungen vermieden, weil weniger
als 1 % aller Pakete um mehr als vier Standardabweichungen zu spät kommen.
Ein Problem mit der dynamischen Schätzung von RTT entsteht dann, wenn zu entscheiden ist, was mit einem abgelaufenen
und erneut gesendeten Segment geschehen soll. Wenn die Bestätigung ankommt, ist nicht klar, ob sie sich auf
die erste oder zweite Übertragung bezieht. Eine Fehleinschätzung kann den RTT-Wert ernsthaft beeinträchtigen. RTT
sollte nicht auf der Basis eins Segments aktualisiert werden, das erneut übertragen wird. Statt dessen wird das Timeout
bei jedem Ausfall solange verdoppelt, bis die Segmente beim ersten Mal durchkommen - man nennt dies den Kern-
Algorithmus. Er wird in den meisten TCP-Implementationen angewandt.

Weiss doch jeder oder ?

 

[[GP] mino]

jetzt schon danke dafür!

 

[DerKleine49]

@joel
"Weiß doch jeder..." Nein.
Danke für die umfangreiche Info.

 

[Sputnik 1]

Das klingt für mich wie cmd_rate und resend bei CS. Sprich wir oft werden die Pakete am den Server gesendet.

Sputnik

 

[Raid`worx]

also besser an oder aus? .... wahrscheinlich merkt man keinen unterschied.

 

[character]

Ausprobieren. Wir kennen deine Leitung nicht.

Da man die Route zum jeweiligen Server (der ja auch noch oefter mal gewechselt wird) aber nicht beeinflussen kann, halte ich einen festen (wenn auch beliebigen) Wert aber ohnehin fuer Unsinn. Theoretisch muesste man den optimalen Wert fuer jeden Server erneut ermitteln.

 

[MoiSon]

Also ich hab da garnix dran gemacht und merke kein Unterschied zu vorher. Wie soll man sich da auch einen optimalen Wert ermitteln? Bis man sich für die Map passend gekleidet, ausgerüsstet und die Waffen angepasst hat ist die Runde eh schon halb um und jetzt soll man noch anfangen an der Inetleitung zufumeln? .

 

[Sabr]

Word

 

[Kha'ak]

Der Regler ist standardmäßig auf 100% eingestellt.
Stellt man 0% ein, dann sieht man schon wie die Models ruckeln, weil das Model dann direkt auf die Hitbox gelegt wird und bei 100% interpoliert es das Model, damit es flüssig aussieht.

Hab DSL 16K mit 17-19ms zu den Servern laut Serverliste.
Im Spiel sieht man nicht seinen eigenen Ping (EPIC FAIL).

 

[MoiSon]

Dann müsste es theoretisch heissen: je kleiner der Wert desto besser. Man sollte also mit dem Regler nach und nach richtung "weniger" gehen bis das Ruckeln als störend empfunden wird was bei jedem ja anders ist (individueles empfinden). Dann vielleicht noch ein Tick zurück richtung "mehr" als Kompromis zu anderen Servern und gut ist. Hmm, werd ich mal testen.

Ach und die Ping Anzeige hätte man sparen können, was man nicht weis macht einem nicht heis...

 

[Kha'ak]

Genau, dann frag einfach ein Squad Mitglied^^

 

[Sputnik 1]

Also ich hatte gestern auch das Gefühl, dass der Inputlag wieder gestiegen ist. nach dem 1. Patch wär es absolut flüssig. Gestern kamen einige Kills wieder Zeit vertsetzt.

Hab an dem Regler gedreht aber es wurde nicht besser. Was machen die nur mit ihrem Netcode oO?

Sputnik

 

[domidragon]

Im Spiel sieht man nicht seinen eigenen Ping (EPIC FAIL).

eben, dass haben sie so gemacht, um das teamplay zu fördern xD

je kleiner der Wert desto besser. Man sollte also mit dem Regler nach und nach richtung "weniger" gehen bis das Ruckeln als störend empfunden wird was bei jedem ja anders ist (individueles empfinden). Dann vielleicht noch ein Tick zurück richtung "mehr" als Kompromis zu anderen Servern und gut ist. Hmm, werd ich mal testen.

so ist es, jetzt kann jeder selber gucken, das er zufrieden gestellt wird...

 

[Sabr]

Ich habs gestern getestet und ganz ehrlich merke ich bei max. bzw min. garkeinen unterschied.
Hab eine 6 k Leitung.

 

[Rush]

Bei minimalen Wert ruckeln die Models der Gegner sowie die Messeranimation, dann ist es zu gering eingestellt und der Regler muss weiter nach "rechts" geschoben werden.



MFG Rush

 

[uFFsel]

Bei minimalen Wert ruckeln die Models der Gegner sowie die Messeranimation, dann ist es zu gering eingestellt und der Regler muss weiter nach "rechts" geschoben werden.



MFG Rush

Danke!
Das hat mein Problem behoben mit dem ruckeln bei der Messeranimation.

 

[Moh4wK]

Im Spiel sieht man nicht seinen eigenen Ping (EPIC FAIL).

Das stimmt so nicht ganz.
Bei BF3 ist es so, dass deine Verbindungen zu jedem einzelnen Spieler angezeigt werden - nicht nur deine zum Server. Deswegen gibt es auch nicht nur "einen Ping" sondern eben soviele, wie Spieler da sind. Der Ping hinter einem Spieler ist also der Ping, den Du zu ihm hast.

 

[SubZero1987]

@Moh4wK

das ist völliger Blödsinn! Wenn du mit ein paar leuten im TS bist und du mal den Ping untereinander vergleichst wirst du es schnell sehen! Warum hab ich z.b. zum Kollegen nen Ping von 25 während nen Kollege der in nem ganz anderen Land wohnt und DEUTLICH weiter weg von ihm wohnt zu meinem Kollegen den selben Ping hat?

Das ist einfach unmöglich! Das wäre ja so als hätte ich nach Deutschland den gleichen Ping wie nach Amerika aber wirklich exakt auf die Millisekunden gleich! Und wenn du weisst was ein Dedicated Server ist würdest du sowas eh nicht behaupten da jeder Spieler mit dem Server kommuniziert und nicht untereinander wie bei Peer-to-Peer! Oder wenn ich mal wieder über mein Handy Internet Spiele und der Ping weit über 100 ist aber Spieler mit einem Ping von 8 rum laufen. ACHSO mit Handy Internet hat man also einen Ping von 8? Guter witz!

Peer-to-Peer


Dedicated Server

Grundlagen der Netzwerktechnik,

Für jede Verbindung verwaltet TCP die Variable RTT (Round-Trip-Time). Das ist die momentan beste Schätzung der
Rundreisezeit zum fraglichen Ziel. Wird ein Segment gesendet, startet ein Timer. Er überwacht, wie lange die Bestätigung
braucht, und löst bei Bedarf eine Neuübertragung aus. Kommt die Bestätigung zurück, bevor der Timer abläuft,
mißt TCP, wie lange die Bestätigung dauerte, z.B. M. Dann wird RTT nach der Formel
RTT = aRTT + (1 - a)M
aktualisiert. Dabei ist a ein Glättungsfaktor, der bestimmt, wieviel Gewicht dem alten Wert beigemessen wird. Ein
typischer Wert ist a = 7/8.
Auch bei einem guten RTT-Wert ist die Auswahl eines geeigneten Timeouts für Neuübertragungen keine leichte Aufgabe.
Zur Anpassung an die Varianz der Übermittlungszeiten wird die geglättete Variable
D=aD + (1 - a)|RTT - M|
als Abweichung gegeben, wobei a nicht unbedingt der gleiche Wert sein muß, der zum Glätten von RTT benutzt
wurde. D ist zwar nicht genau das gleiche wie die Standardabweichung, aber gut genug. Die meisten TCP-Implementierungen
benutzten heute diesen Algorithmus und setzen das Timeout-Intervall auf
Timeout = RTT + 4 x D
Die Auswahl von Faktor 4 ist mehr oder weniger arbitär, hat aber zwei Vorteile. Erstens sind Multiplikationen um 4
ohne Verschiebungen möglich. Zweitens werden unnötige Timeouts und Neuübertragungen vermieden, weil weniger
als 1 % aller Pakete um mehr als vier Standardabweichungen zu spät kommen.
Ein Problem mit der dynamischen Schätzung von RTT entsteht dann, wenn zu entscheiden ist, was mit einem abgelaufenen
und erneut gesendeten Segment geschehen soll. Wenn die Bestätigung ankommt, ist nicht klar, ob sie sich auf
die erste oder zweite Übertragung bezieht. Eine Fehleinschätzung kann den RTT-Wert ernsthaft beeinträchtigen. RTT
sollte nicht auf der Basis eins Segments aktualisiert werden, das erneut übertragen wird. Statt dessen wird das Timeout
bei jedem Ausfall solange verdoppelt, bis die Segmente beim ersten Mal durchkommen - man nennt dies den Kern-
Algorithmus. Er wird in den meisten TCP-Implementationen angewandt.

Weiss doch jeder oder ?

Danke aber dein Text sagt mir jetzt 0 wie ich im SPIEL den wert einstellen soll (was der TE ja fragt!) da es ein balken ist

 

[r00t]

Es gibt also scheinbar immer noch Spieler die überraschend grundlos sterben obwohl sie eigentlich schon längst um die Ecke sind .. dabei wollte EA beziehungsweise DICE doch mit dem letzten Patch den Netcode generalüberholen und verbessern.

Den Regler kann man grob vergleichen mit dem com_maxfps und cl_maxpackets von Call of Duty, wenn ich das Prinzip dahinter richtig verstanden habe regelt es die Zeit die es braucht, bis ein verlorengegangenes Paket neu gesendet wird, je schneller die Internetverbindung beziehungsweise je besser das Routing ist, desto größer kann der Wert sein. (Nagelt mich bitte aber nicht darauf fest, meine Netzwerktechnikkenntnisse sind .. "eingeschränkt vorhanden". )

//Edit:
"Interpolation" in der Beschreibung lässt eben auch auf eine "Auffrischungsrate" tippen.

//Edit II:
Es gibt hierzu auch Forenbeiträge, die ich dank des Linkschutzes (.. welche Links gelten eigentlich als sicher, wenn das Battlelog von EA nicht gilt? o_O) Der englische Begriff, "Network Smoothing" bringt schnell die gewünschten Suchergebnisse. Auch ganz interessant:

Set it at minimum for best hitreg, less dieing in cover, less instant deaths, more choppy animations. The setting is 100% client side, it will not affect what info u get or send to the server. All it does it reduces the extra "guesses" added by the client to make the animations smooth.

So, lowering the bar will make you see more precise actions and locations of stuff ingame (soldiers, vehicles etc.) but u will suffer in animations, especially in crowded areas like metro 64 conquest, where you will see a lot of jerky animations. BUT! I will take the jerky animations any time of the day instead of dieing in cover and having false hit registers!