Denn nur weil ihm die benötigte Bandbreite zugeschrieben wird, gehen doch trotzdem Ping und Latenz bei Vollauslastung der Leitung in den Keller, oder irre ich mich? Dann würde er ja einen nicht nutzbaren Bandbreitenpuffer benötigen.
Wie das bei der alten Firmware wirklich aussieht und was da zu regeln ist, weiß ich auch nicht mehr. Auch sind die ganzen Überlegungen zum Spielen ja reine Spekulation ... aber man darf ja trotzdem nachdenken.
Für seine Latenzprobleme sollte es eigentlich ausreichend sein (bzw. das ist das einzige, was er wirklich machen kann), wenn seine eigenen Pakete vorne eingereiht werden bei den zu sendenden Daten (Priorisierung). Eine Reservierung gelingt ihm am Ende ohnehin höchstens im Upstream, da sollte aber die Priorisierung auch reichen ... wenn ein von ihm eingehendes Paket vor allen anderen in Richtung Internet weitergeleitet wird, ist das - vorausgesetzt der Stau entsteht nicht
hinter dem Router in Richtung Internet - imho so ziemlich dasselbe,
Mal grob gerechnet: 384KBit/s im Upstream = 384*1024/9 (damit der Overhead drin ist) ~ 43600 Byte/s = knapp 30 "volle" Pakete/s -> etwas über 30 ms Verzögerung schon im eigenen Router, wenn's schlecht läuft. Das ändert sich aber auch nicht, wenn da eine Bandbreite reserviert wurde, denn der Sendevorgang für das vorherige Paket wird ja nicht spontan unterbrochen, nur weil da plötzlich eines mit höherer Priorität auftaucht. (Im Downstream ergäbe das dann bei 6000 KBit/s eine max. Latenz von knapp über 2ms ... aber das ist eine andere und von ihm nicht zu beeinflussende Baustelle.)
Ein schmaler Upload (wenn man ihn nicht zu jeder Zeit garantiert sofort benutzen kann), bringt eben auch eine Latenz im Upload mit sich. Wenn die Bandbreite im Upload das Dreifache beträgt (bei dem vorherigen 16.000er-Anschluß m.W. die Regel), ist eben schon dadurch auch die Latenz beim Senden auf ein Drittel verringert.
Wenn die WG-Mitbewohner wirklich streamen (damit meine ich, Filme
sehen), brauchen sie - je nach Protokoll beim Streamen - ja den Upload ohnehin nur in sehr bescheidenem Umfang und mit sehr kurzen Paketen (wenn überhaupt ACKs gesendet werden).
Den beim Router von extern eingehenden Datenstrom kann er ohnehin nicht richtig steuern. Er kann nur drosseln, wieviel davon pro Zeiteinheit an den Client weitergeleitet wird und damit dann eben auch, wieviel dieser Client quittiert, was dann am Ende auch den eingehenden Strom regeln
kann, aber nur bei TCP-Verbindungen. Bei UDP-basierten Streams kommt das beim Router immer mit der maximalen Rate an, die das Netz bis dahin hergibt. Da es keine Quittungen gibt, merkt der Sender gar nicht, ob das alles richtig beim Empfänger ankommt oder nicht. Er sendet es einfach, Schwund unterwegs ist per Definition möglich. Wenn das am Ende schneller ist, als es wiedergegeben wird, wird es eben beim Empfänger gepuffert. Nur in ganz seltenen Fällen wird der Empfänger den Sender um eine Pause bitten.
Bei einem Protokoll mit Transportsicherung (also da, wo sichergestellt wird, daß auch alle Daten richtig angekommen sind), kann das genauso zu Bursts führen, wenn der Sender da dann mal einige Pakete am Stück erneut senden muß. Beim TCP wird eine bestimmte Anzahl von Paketen (die Window Size legt fest, wie viele) erst einmal "blind" auf die Reise geschickt und dann wird auf die entsprechenden Quittungen des Empfängers gewartet. Bei dem können die Daten auch in anderer Reihenfolge ankommen, er sortiert sie in seinem Empfangspuffer wieder richtig und bestätigt den Erhalt. Für jedes quittierte Paket könnte der Server nun ein weiteres schicken, aber i.d.R. wird auch er eine Pause einlegen, wenn ein noch vorgehaltenes Paket vom Empfänger schon länger nicht bestätigt wurde (das kann ja auch daran liegen, daß es komplett verloren gegangen ist und nicht nur an der Verzögerung der Quittungspakete). Wenn dann plötzlich der komplette Sendepuffer leer ist, sendet der Server wieder bis zur maximalen Window Size und so kann sich - u.a. bei "schlechter Übertragung" der ACK-Pakete - ein "schubweiser" Verkehr aufbauen, dem eigentlich mit "Congestion Control" entgegengewirkt werden soll.
Da führt dann eine Limitierung zwar im Mittel zu einer verringerten Belastung der Leitung, die DS-Latenz zu einem bestimmten Zeitpunkt kann man damit aber nicht wirklich steuern ... wenn's voll ist, ist's voll und wenn der
vorgelagerte Router nicht weiß, daß er die Pakete an den TE vor allen anderen übertragen muß, dauert es eben, bis er an der Reihe ist.
Da ist dann schon mal ein Geschoß oder eine Kampfbewegung des Gegners schneller angekommen/ausgeführt, als der Spielteilnehmer es mitbekommt. Wenn dann der Server als zentrale Instanz das zu Ungunsten des Spielers wertet, ist das ja auch nachvollziehbar, was kann der Gegner für die schmale Leitung.
Eine Reservierung von Bandbreite (so sie für Spieler überhaupt Sinn macht, die Latenz für ein
einzelnes Paket ändert sich dadurch ja gerade nicht) im Upstream ist Sache des Routers, eine Reservierung im Downstream wäre Sache des DSLAM - meines Wissens unterstützen die meisten Provider nicht mal ordentlich TOS/QOS für IP-Pakete. Wenn da irgendwas reserviert wird, ist da - zumindest bisher so gewesen - immer ein zweiter PVC beim ATM für die Telefonie, der dann wegen der eigenen garantierten Bandbreite im ATM eine QOS-Garantie ermöglicht.
Insofern ist halt ein "schlechter Ping" nur dann zu beheben, wenn man weiß, wie er konkret zustande kommt. Einfach mal "auf Verdacht" da ein Traffic Shaping durch Drosselung einzelner Teilnehmer zu machen, bringt nur "im Mittel" etwas und wirkt sich auf die
Latenz einzelner Pakete (wenn da nicht zig Pakete im Upstream warten und man sich hinten anstellen muß) eher nicht aus. Wenn man nicht auf den Versand seiner Mails mit Anhang die doppelte Zeit warten will, dann
kann es etwas bringen, wobei auch dann für einen einzelnen Teilnehmer die Priorisierung (weg da, ich bin Arzt) bessere Ergebnisse für alle bringen sollte. Bei Echtzeitanwendungen wie IP-Telefonie ist eine Bandbreitenreservierung etwas anderes ... aber auch da wird durch die Reservierung die Latenz nicht direkt beeinflußt.
Just my 2 cents ...
