-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Lohoff schrieb: | On Mon, May 05, 2003 at 12:41:05PM +0200, Pierre Bernhardt wrote: | |>Weiss ich. Es wird aber auch nur gedroppt, wenn die zugehörige Bandbreite |>berbraten ist. Ergo schickt dann der Source-Rechner die Pakete nicht mehr |>so schnell und das ist das, was ich brauche. |>Praxis: Seit dem ich auch Eingangsseitig begrenze, sind meine Pingraten |>und Paketverluste bei z.B. bei CounterStrike massiv verbessert worden. |>So habe ich jetzt keine Paketverluste mehr und meine Pingrate ist steigt |>gerade mal um 30 ms an. Gegenüber +2000ms vorher.... | | | Kann ich kaum nachvollziehen Welchen Teil? - - Im allgemeinen ist der Upstream deutlich | kleiner als der Downstream. Richtig. Die ACKs gehen ja in den Upstream und die sind auch sehr klein; verhältnismässig wesentlich kleiner als die ankommenden WWW und ftp-Pakete von großen Dateien (can 1500down : 70up) Wenn du deinen parallel laufenden mldonkey | begrenzen moechtest im incoming wuerde ich im outgoing die ACK pakete | limitieren. Leider bleibt das verhältnis nicht gleich zwischen up und downstream. Der Upstream breaucht eigendlich nur selten begrenzt werden, da ich dort nur selten tatsächlich eine hohe Auslastung habe. Was begrenzt werden muss, ist der Downstream. Und das nur deswegen, weil sich die Pakete bei T-Offline stauen. Ich helfe dem ab, in dem sich die Pakete in meinem Router1 stauen. Das kostet mich zwar mögliche Bandbreite (im Moment habe ich es gut mit 700kBit im Down und 110kbit im Up laufen), aber es hilft mir, massiv Ströme zu priorisieren. |>Ergo: Auch das wegwerfen von Paketen kann positiv sein. Ich schicke |>aber trotzdem braf die ICMP-Pakete zurück, in der Hoffnung, das der eine |>oder andere Router diese nicht wegwirft und auswertet. Ansonsten sind |>ja noch die tcp-ack-Pakete da, welche ich auch priorisiert habe. | Genau das solltest du nicht machen - Counter strike ist UDP richtig ? | Also das priorisieren und im tcp die ACKs outgoing verwerfen damit | incoming weniger kommt. Ja. Wo liegt aber das Problem? Die UDP Pakete haben eine höhere Prio als die WWW-Pakete. Dadurch werden die schneller durch meinen Router durchgereicht. Die Pakete die also zuerst weggeworfen werden, sind von anderen Ports wie http, ftp, ... Ich habe dabei aber nicht vergessen, dem favorisierten CS-Paketen eine Mindestbandbreite von 150kbit zu reservieren. WWW darf auch 450 kbit haben. Wenn www mehr will, dann darf er bis auf 650 kbit hoch, sich etwas vom nicht benutzten CS-Kanal borgen. So garantiere ich eine geringe Durchlaufzeit von CS-Paketen, ohne, dass sie weggeworfen werden. Wie gesagt, mach ich das mit dem htb-Modul und passenden iptables -mangle Regeln. Ob das mit der Eselei auch noch gut funktioniert, kann ich noch nicht sagen, da ich das noch nicht getestet habe. Bei ftp und www bekomme ich gute 70KByte downstream und habe max. Pingraten von 100ms in cs gegenüber sonst 50ms, wenn ich direkt mit dem PC verbunden bin. Im allgemeinen liegen die Pingraten aber bei etwa 70-80 zu 30-40 ms bei vollen Downstream zu CS-Only-Downstream. Vorher waren es eher an die 2000ms, wenn die Leitung mal wieder belegt war. Das Problem ist also quasi schon gelöst gewesen. Mein Problem liegt aber an anderer Stelle, nähmlich der, dass ich in dem 2. Router ein haufen Interfaces habe. Durch eine besagte Pipe, könnte ich den Downstream auf die Pipe anwenden. Alle Donwstreampakete werden dann hinter dieser Pipe an die Interface weiter geroutet. Das war meine Frage. Inzwischen habe ich was von einem imq gelesen, mit dem möglich sein könnte. MfG... Pierre PS: Warum tust Du das der Liste vorenthalten? Auch wenn es nicht nur um linux geht, so ist es doch hauptsächlich ein Problem, welches mit Linux gelöst werden soll. Es gibt genügend Leute, die das ein ähnliches Problem haben. Diese könnten daraus dann ebenfalls partizipieren. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE+tl8ouOJP+ESj7AoRAgxBAJ95ZVWO99udbbD2gresn8usXKUXdgCbBFi4 h9ZKaCft9zI+6jEst9IeooE= =z4Kt -----END PGP SIGNATURE-----