Netzwerkpipes unter linux

[Pierre Bernhardt]

-----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-----