Re: traffic shaping -- was geht?
Am Sonntag, 21. Mai 2006 15:28 schrieb Christian Schnobrich:
> On Sun, 2006-05-21 at 12:27 +0200, Markus Schulz wrote:
> > Jetzt die Gute Nachricht: es gibt Patches, die eine dynamische
> > Overhead Berechnung im HTB
> >
> > 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.
>
> Kann ich dem im Umkehrschluß entnehmen, daß ich schon das Maximum
> rausgekitzelt habe, das ohne Patch zu haben ist?
>
> Bzw, ich glaube nicht, daß diese Vergrößerung der ACKs das
> eigentliche Problem darstellt. Überspringe mal die nächsten beiden
> Absätze, dann gehts weiter...
[...]
Aehm, du hättest sie vielleicht doch lesen sollen. Ich glaube nämlich du
mißverstehst mich. Es geht mir ausschliesslich um die Upstream (egress)
Bandbreitenkontrolle. Dafür wurde HTB auch geschaffen, es läßt sich mit
ein Paar Tricks zwar auch für den Downstream (ingress) benutzen, dort
ist es natürlich nicht wirklich sinnvoll, da die Daten ja schon
angekommen sind und maximal gedropped werden können. Teilweise kann man
damit auch schon brauchbare Ergebnisse erzielen und als Ergänzung
sollte man immer irgend einen ingress filter verwenden.
Das das ganze dem Zweck dient Queues in dem Modems/ISPs zu verhinden ist
klar, nur dann läßt sich die Latenz jeder Verbindung direkt
beeinflussen.
Jetzt aber zu meinem eigentlichen Anliegen, htb(und andere)
QoS-egress-Module in Standard Kernel, können _nie_ den Upstream korrekt
handhaben. Denn sie wissen nur was netto über die Leitung rausgehen
soll, aber nicht wieviel das Brutto auf der ATM Strecke ergibt. Deshalb
liest du in jedem QoS HowTo das du den Upstream um 5-10% unter das
maximal mögliche legen sollst. Und genau dafür dient die von mir
erwähnte Variante, die ist darauf nämlich nicht angewiesen und kann den
Upstream 100% korrekt handhaben. Damit kann man die Bandbreite sehr gut
kontrollieren, schliesslich ist der Downstream vom Upstream (zugehörige
ACK Pakete) direkt abhängig.
Die nächst bessere Variante wäre es die Flusskontrolle von z.B. TCP/IP
zu manipulieren, damit könnte man sogar direkt den Downstream
beeinflussen ohne zu droppen, indem man das Sliding Window der TCP
Verbindung verändert. Dafür gibt es aber iirc bisher keine freien
Implementierungen.
Das ganze wird hier aber mega-OT. Bei Interesse empfehle ich die
erwähnte Master-Arbeit als Einstieg zu lesen und auf der LARTC-ML
weiter zu diskutieren.
--
Markus Schulz
UNIX is user friendly, it's just picky about who its friends are
Reply to: