Trafficshaping klappt nicht

[phone-man]

Hallo

Ich möchte Asterisk eventuell bald produktiv einsetzen, nur muß dazu das Trafficshaping einwandfrei funktionieren, damit man störungsfrei telefonieren kann.
Ich habe inzwischen diverse Scripts aus dem Netz angepasst und ausprobiert aber bei jedem Test hört mein Gesprächspartner starke Aussetzer und Knackgeräusche im Falle eines Ftp-Uploads oder Mailversandes.

Ich habe nun vorerst folgende einfache Konfiguration verwendet, um Fehler auszuschliessen aber selbst hier gibt es die gleichen Probleme:

# root qdisc anlegen
tc qdisc add dev ppp0 root handle 1: htb default 10

# root class anlegen
tc class add dev ppp0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit

# zwei gleichberechtigte Klassen anlegen
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 50kbit ceil 50kbit
tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 50kbit ceil 50kbit

# Pakete vom Asterisk Server markieren
iptables -A POSTROUTING -t mangle -o ppp0 --src 192.168.0.100 -j MARK --set-mark 12

# Mit dem Wert 12 markierte Pakete in die Klasse 1:11 leiten
tc filter add dev ppp0 parent 1: prio 10 protocol ip handle 12 fw flowid 1:11

Hiernach hat der Asterisk Rechner immer 50kbit/s Bandbreite zur Verfügung und alle anderen Rechner fallen in die Default Klasse.
Der Datenverkehr wird auch einwandfrei in die beiden Klassen eingeordnet, so daß es eigentlich funktionieren müsste aber sobald ein Ftp-Upload läuft, kann man die Sprachqualität vergessen.

Der Router ist nahezu überhaupt nicht ausgelastet. Woran kann das liegen, daß trotzdem keine einwandfreie Verbindung möglich ist? Ich habe auch schon diverse Codecs ausprobiert aber dies brachte keine Unterschiede.

[Netview]

Ähmm - ich denke du hast ganz sicher das 'traffic shaping'/QoS auf dem Router aktiviert - denn nur von dort aus ist die Priorisierung des Datenverkehrs möglich (nicht auf einem client wie z.B. *)!

Welcher Router läuft denn bei dir?

[phone-man]

Natürlich habe ich das Trafficshaping nicht auf dem Cleint eingerichtet
Sonst würde der Traffic ja auch nicht in Klassen eingeordnet werden können, wie ich beschrieben hatte.

Als Router läuft ein Debian Sarge. Im Kernel sind alle nötigen Optionen aktiviert.

[Netview]

Zitat von phone-man

Natürlich habe ich das Trafficshaping nicht auf dem Cleint eingerichtet
Sonst würde der Traffic ja auch nicht in Klassen eingeordnet werden können, wie ich beschrieben hatte.

Als Router läuft ein Debian Sarge. Im Kernel sind alle nötigen Optionen aktiviert.

Da du Fragen zu QoS gestellt hast macht es natürlich Sinn Angaben zum Router zu machen (der * als client spielt da ja eher eine untergeordnete Rolle)!

Im übrigen gibt es Artisten die QoS auf dem * eingerichtet haben und sich wunderten, dass nix funktionierte!

Deswegen meine "ironische" Anmerkung!

[phone-man]

Auf dem Router läuft Masquerading um den dahinterstehenden Rechnern via NAT Zugang zum Internet zu gewähren.

Falls weitere Infos nötig sind, bitte fragen. Das bevorzugen der Bestätigungspakete bei Downloads in der Upload Queue funktioniert ebenfalls, von daher gehe ich davon aus, daß das Trafficshaping im Grunde funktioniert. Um so weniger verstehe ich, daß bei Auslastung der Default Klasse trotz ausreichend zugesicherter Bandbreite in der Asterisk Klasse keine störungsfreien Gespräche möglich sind.

[Netview]

vielleicht hilft dir dies weiter:

http://www.voip-info.org/wiki-Asterisk+QoS
http://www.voip-info.org/wiki-QoS+Linux

[phone-man]

Das hilft leider nicht weiter. Ich habe bereits diverse Scripts getestet und im Prinzip arbeiten diese ja auch alle gleich, abgesehen von den eingesetzten Schedulern htb oder sfq.
Das im ersten Posting stehende Script ist ja im Prinzip eine einfache Forum, wie viele Scripte im Netz auch arbeiten, nur beinhaltet diese eben nur 2 Klassen, eine für Asterisk und eine für den Rest. Und solange das nicht funktioniert, brauche ich ja nicht alles noch verkomplizieren und weitere Klassen für andere Dienste wie ssh etc. einzubauen.

[traxanos]

Das Problem ist das HTB und SFQ die ja von fast allen Trafficshappern verwendet werden für VoIP nichts taugen.

HTB sorgt zwar dafür das genügend Bandbreite zur Verfühgung steht, aber es besitzt keine Prioritäten. Somit sind die Latenzen immer noch nicht geregelt.
PS: Die Prio bezieht sich darauf wer zuerst Bandbreite erbt.

SFQ sorgt nur das mehrere Verbindungen gleich behandelt werden. Da eMule aber hunderte von Verbindungen aufbaut ist hier auch wieder VoIP benachteiligt.

Es gibt zwar noch mehr Scheduler aber auch bei dennen gibt es ähnliche Probleme. Allerdings gibt es hier auch Scheduler die die Latenz beinträchtigen.

Streaming-Anwendungen brauchen ein Queueing, das Verzögerungen vermeidet. Hier hilft der Vergabe von Bandbreite (HTB) nur bedingt.

Beispiel aus einem Artikel des Linux Magazin

Angenommen jedes zu sendene Paket ist 1500Byte groß und alle Klassen senden mit maximaler Kapazität. Aufgrund der Leitungskapazität von 1000KBit/s dauert es 12 millisekunden, um ein Datenpaket zu versenden: 11500Byte/Paket * 8Bit/Byte / 1 000 000 Bit/s = 12ms/Paket. Sendet die VoIP-Anwendungmit 100 Kbit/s, dann sind das bei 1500-byte-Paketen etwas acht Pakete pro Sekunde: 1 000 000 Bit/s / ( 1500 Byte/Paket * 8 Bit/byte) = 8,33 Pakete/s. Um die garantierte Rate von 100KBit/s für diese Klasse einzuhalten, muss die QDIsc spätestens alle 120 Millisekunden ein Datenpaket der Klasse versenden: 1 Paket / 8,33 Pakete/s = 0,12s. Daraus ergibt sich eine Maximalverzögerung von etwas 13ms pro Paket. (120+12)

Das Beispiel illustriert die enge Verflechtung von Bandbreite und Verzögerungszeit.

Für alle die nach einem guten Scheduler suchen, sollten sich den HFSC-Algorithmus anschauen.

Deswegen wird QoS für VoIP immer ein Problem bleiben, da diese Filter auf die jeweiligen Anwendungen angepasst werden müssen.

Eine immer funktionierende Fertiglösung wird es daher kaum geben können.
Das ist was ich andauernd probiere

[phone-man]

Vielen Dank für diesen sehr hilfreichen Beitrag.

Hast du mit dem HFSC Scheduler schon Erfahrungen gesammelt bzw. gibt es irgendwo Infos, wie man diesen in den Linux Kernel patchen kann? Eine kurze Recherche ergab, daß Infos zu HFSC sehr rar sind.

[Honk]

@traxanos:

Kannst du den Link zum Artikel des Linux-Magazins bitte noch posten, sofern vorhanden?

Danke und Gruß

[traxanos]

Leider gibt es keinen ich habe es nur als Zeitschrift vor mir liegen.
Selber habe ich leider noch keine Erfahrungen sammeln können.
Allerdings ist mir in den letzten Versionen aufgefallen das dieser
Scheduler erst neu dazu gekommen ist. Ich gehe davon aus das
evtl die meisten Router nicht per SSH modifizierbar sein werden.

[udosw]

Ich plage mich auch schon den ganzen Abend mit dem QoS rum.

Das Script myshaper (zu finden u.a. in http://www.nslu2-linux.org/wiki/HowT...TrafficShaping) funktioniert bei mir noch am Besten, allerdings wie traxanos schon sagt: Bandbreite allein reicht nicht.

Ich hab dann mal versucht, myshaper sozusagen auf hfsc umzubauen, aber das klappt auch nicht.

Ich hab auch über den Artikel im Linux-Magazin gebrütet, aber ich verstehe die Syntax der tc-Befehle und deren Bedeutung einfach nicht richtig.

Irgendwie bin ich immer noch am Überlegen, ob man das Routing nicht lieber mit irgendeinem schönen Hardware-Router machen sollte, statt in Eigenarbeit mit der Linux-Büchse.

Wie sind denn da so die Erfahrungen?
Udo

[udosw]

Sorry, dass ich das hinterherschiebe:
Problem gelöst: http://www.ip-phone-forum.de/forum/v...ic.php?t=14148

Udo