.titleBar { margin-bottom: 5px!important; }

Trafficshaping klappt nicht

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von phone-man, 26 März 2005.

  1. phone-man

    phone-man Neuer User

    Registriert seit:
    27 Feb. 2005
    Beiträge:
    89
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    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:
    Code:
    # 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.
     
  2. Netview

    Netview IPPF-Promi

    Registriert seit:
    1 Apr. 2004
    Beiträge:
    3,366
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Dipl.-Inf.
    Ort:
    Westerwald
    Ä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?
     
  3. phone-man

    phone-man Neuer User

    Registriert seit:
    27 Feb. 2005
    Beiträge:
    89
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Natürlich habe ich das Trafficshaping nicht auf dem Cleint eingerichtet :lol:
    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.
     
  4. Netview

    Netview IPPF-Promi

    Registriert seit:
    1 Apr. 2004
    Beiträge:
    3,366
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Dipl.-Inf.
    Ort:
    Westerwald
    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!
     
  5. phone-man

    phone-man Neuer User

    Registriert seit:
    27 Feb. 2005
    Beiträge:
    89
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    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.
     
  6. Netview

    Netview IPPF-Promi

    Registriert seit:
    1 Apr. 2004
    Beiträge:
    3,366
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Beruf:
    Dipl.-Inf.
    Ort:
    Westerwald
  7. phone-man

    phone-man Neuer User

    Registriert seit:
    27 Feb. 2005
    Beiträge:
    89
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    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.
     
  8. traxanos

    traxanos Mitglied

    Registriert seit:
    15 Juli 2004
    Beiträge:
    486
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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

    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 ;)
     
  9. phone-man

    phone-man Neuer User

    Registriert seit:
    27 Feb. 2005
    Beiträge:
    89
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    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.
     
  10. Honk

    Honk Neuer User

    Registriert seit:
    3 Okt. 2004
    Beiträge:
    108
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    Hamburg
    @traxanos:

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

    Danke und Gruß
     
  11. traxanos

    traxanos Mitglied

    Registriert seit:
    15 Juli 2004
    Beiträge:
    486
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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.
     
  12. udosw

    udosw Aktives Mitglied

    Registriert seit:
    20 März 2004
    Beiträge:
    1,114
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Ort:
    Hannover
    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/HowTo/EnableTrafficShaping) 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
     
  13. udosw

    udosw Aktives Mitglied

    Registriert seit:
    20 März 2004
    Beiträge:
    1,114
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Ort:
    Hannover