Re: traffic shaping -- was geht?
Am Sonntag, 21. Mai 2006 03:16 schrieb Christian Schnobrich:
> Hallo,
>
[...]
> Derzeitiger Aufbau:
>
> prio 1 -- für die spieler
> prio 2 -- nicht genutzt
> prio 3 -- der ganze Rest, wird durch HTB geschickt (rate/ceil 15kB)
>
> htb 1 -- kleine Pakete (ACKs), rate 7.5 ceil 15 (alles kB/s)
> htb 2 -- smtp & ftp, rate 3 ceil 15
> htb 3 -- Tauschbörse, rate 1 ceil 15
> htb 4 -- alles andere, rate 4.5 ceil 15
>
> Eigentlich kann die Verbindung 192kbit (24kB) / Sekunde. I hatte
> gehofft, davon 20kB nutzen zu können -- aber selbst wenn ich den
> Spielern keine Extrawurst braten würde, ab 18kB sind sich alle
> Dienste spürbar im Weg.
>
> Dabei habe ich HTB im Verdacht, es mit der eingestellten Rate nicht
> allzu genau zu nehmen -- in Ermangelung fortgeschrittener Werkzeuge
> kann ich die ausgehenden Daten nur in gkrellm beobachten, aber der
> Verlauf scheint mir schon ziemlich wellig zu sein.
Dein Problem ist etwas komplizierter. Ich nehme mal an du verwendest
einen DSL Anschluss via pppoe. Dabei ergibt sich folgende Problematik
für HTB und Co., ein Paket das Netto z.B. 40 Byte groß ist (kleinstes
TCP/IP Paket, z.B. für ACK von Download Paket) muss jetzt noch verpackt
werden, damit es via Ethernet und anschließend ATM transportiert werden
kann.
Das sieht dann ca. wie folgt aus:
TCP/IP (40) + MAC (14+4) + PPP (2) + PPPOE (6) + LLC (10) + AAL5-Tail
(8)
Die Zahlen in Klammern entsprechen der Byte Anzahl. Wie man sehen kann
wird aus einem 40 Byte Paket 40 + 44 Byte Paket. Wenn man jetzt noch
beachtet, das auf der DSL Strecke via ATM übertragen wird, vergeudet
man noch mehr Platz, denn man braucht für das eine ACK Paket jetzt
exakt 2 ATM Zellen (2*53 Byte, wobei 48 Byte Payload pro Zellen zur
Verfügung stehen).
Dein System wollte also 40 Byte TCP/IP übertragen, dein DSL mußte dafür
aber 2*53 Byte opfern.
Wenn du jetzt viele ACK Pakete transportierst (eher die Regel),
vergeudest du eine Menge deiner Upstream Bandbreite, ohne das HTB und
Co davon etwas merken.
Jetzt die Gute Nachricht: es gibt Patches, die eine dynamische Overhead
(statisch, ohne Patch für Kernel Modul nicht möglich) Berechnung im HTB
(oder anderen QOS Modul) durchführen. Jesper Dangaard Brouer hat zu
diesem Thema auch eine Master Arbeit verfaßt, die findest du unter
www.adsl-optimizer.dk
Damit kann man eine QOS Lösung baut die selbst bei maximaler Belastung
des Upstreams, jeder Klasse die gewünschte Bandbreite zur Verfügung
stellt.
--
Markus Schulz
modprobe windows
modprobe: This module will TAINT the kernel
Reply to: