SipShaper: QoS mit HFSC - bei mir klappt's super!

[klaymen]

Ich glaube, ich hab jetzt ne Lösung gefunden... ich habe unter http://developer.osdl.org/dev/iproute2/download/ die aktuelle Version von iproute2 (2.6.11) heruntergeladen und (mit meinen Kernel-Sourcen) neu übersetzt... allerdings die Sache nicht installiert, sondern lediglich das daraus entstandene tc-Executable statt dem in /usr/sbin benutzt. Jetzt scheint der Skript problemlos zu gehen (wie gut es funktioniert, weiss ich natürlich noch nicht). Ich schicke Dir das Executable als pn, vielleicht klappt das ja bei Dir auch gleich, ohne dass Du das ganze Ding neu kompilieren musst. Viel Erfolg!

klaymen

 

[klaymen]

OK, die Sache klappt bei mir recht gut. Was mich allerdings doch noch interessieren würde ist, was die Parameter des hfsc-Schedulers bedeuten? Ich bin zwar auf ein paar Papers zum Scheduler gestossen, wo das Prinzip einer Service Curve erklärt ist - aber woring sich eine "ul", "rt", "ls" und "sc" Kurve unterscheiden, weiss ich nicht. Aus dem Source entnehme ich, dass "rt" offenbar für "RealTime", "ls" für "Link-share" und "ul" für "Upper-Limit" steht, aber das ist auch schon Alles (keine Ahnung, was z.B. "sc" bedeuten soll - ausser sevice curve, aber das wäre dann ja ein Pleonasmus). Ist das irgendwo elektronisch dokumentiert?

 

[phone-man]

Ich möchte hfsc gerne in meinen 2.4er Kernel patchen. Weiß jemand, wie ich dies mit dem Patchfile linux-2.4.25-pre7-hfsc.diff anstelle?

 

[traxanos]

der 2.4.25 kann das doch sowiso? Den dran das der Patch der Pre7-Version gilt und in der Endversion bereits integriert wurde. Solltest du wirklich eine pre7 verwenden kannst du das mit patch tun:

gehe ins kernel verzeichnis und dort
patch -p1 --dry-run -E | cat pfad/file.diff testeb
und ohne --dry-run schreiben.

 

[britzelfix]

Hi traxanos,

warum 2.4.25? pre-patches werden auf die Vorgänger-Version
angewendet, also die 2.4.24 :mrgreen:

Gruß
britzelfix

 

[traxanos]

es gab ne linux-2.4.25-pre7 und eingtlich ist der patch dann auch nur für diese version. aber wie gesagt ich enpfehe sowiso wenn den 2.4.27 der hat es und läuft sehr stabil. 2.4.29 kann man aber auch getrost verwenden ;=)

 

[phone-man]

Alles klar, denn war es im Prinzip nur ein Mißverständnis. Ich war davon ausgegangen, daß hfsc in keinem 2.4er Kernel standardmäßig enthalten ist, weil sämtliche mir bekannten QOS Scripte meist htb oder ähnliches einsetzen, obwohl dies eben nur bedingt für Voip geeignet ist.

Ich werde dann mal mein Glück mit hfsc versuchen, ob damit störungsfreie Voip Gespräche neben gut ausgelasteter Internetleitung möglich sind.

 

[cibi]

Hat (noch) jemand ein Praxistest mit hfsc gemacht?
Ich habe gerade nur IPCop als Router laufen, da ist das wohl etwas komplizierter, hfsc zu integrieren.

Wahrscheinlich geht aus für schnelle Tests mit Knoppix, dort hfsc Support vorhanden. (allerdings habe ich es noch nicht als Router getestet)

Bin gerade dabei openwrt.org (Linux FW für diverse Router, u.a. Linksys,Siemens,etc). mit hfsc zu kompilieren: dort muss man lediglich das hfsc Modul in der Kernelkonfig aktivieren, tc ist bereits aktuell.

Edit/Antwort zu ypsilon Beitrag (s.u.):
Ich hatte ganz vergessen, das das hfsc modul in ipcop vorhanden ist, bin mir nur nicht so sicher ob sich eine neuere version von tc/iproute2 so einfach integrieren lässt.
Bei mir kommt nich hinzu, das ipcop in einer uml Umgebung läuft (c't server).

Update II:
Bei c't debian server + uml ipcop geht auch das tc bin aus dem Debian Server (beides auf aktuellem Stand). Ich kenn mich aber nicht aus, was die tc/iproute/kernel Verknüpfung angeht, deshalb k.A. ob das so das ware ist bzw. zu Problemen führt.
Bei max. Upload (z.B. knoppix per BT) habe ich zwar noch Störungen (Knattern), aber auf jedenfall deutlich besser als meine htb Versuche. Vielleicht lässt sich das noch optimieren.

 

[ypsilon]

hi cibi,

ipcop ist doch wunderbar und HFSC ist im Kernel vom Cop auch integriert!!!

# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_CSZ=m
CONFIG_NET_SCH_HFSC=m

Das was im COP allerdings nicht aktuell ist die aktuelle Version von iproute2 (2.6.11) das stimmt, ist für tc wichtig!

bye bye

yps

 

[johuebner]

Praxistest

Hallo,

wirklich hilfreich, dieses Forum - Respekt!
Als Feedbach hier ein Ergebnis meines Praxistests:
Ich benutze:
-Fedora Core 1 mit Kernel 2.6.11.6
-bristuff-0.2.0-RC7k also Asterisk 1.0.6
-iproute-2.6.11-1
iproute-2.4.x war bei Fedora 1 dabei, Version 2.6 habe ich mit --nodeps installiert, was dazu führt, dass arpd nicht geht - brauch ich eh nicht.
Sip-Provider sind web.de und gmx
DSL-Provider ist Arcor, Anschluss ist 128/1024

Ich habe also mldonkey gestartet und dem Upload keine Grenzen gesetzt, laut Anzeige hat er mit 13,x kb/s hochgeladen.
Dann habe ich Mitbewohner 1 auf dem ISDN-Anschluss angerufen.
Ergebnis: immer noch ziemliche Verzögerung, Sprachqualität wie bei GSM mit schlechtem Empfang. Aber schonmal besser als ganz ohne tc. Mitbewohner 2 beschwerte sich allerdings, dass das Internet bei ihm so langsam war, dass er aus einem Chat geflogen ist.

Daraufhin ACK-Pakete in die "schnelle Klasse" geschickt, also

iptables -A SIPSHAPER -t mangle -p tcp -m length --length :64 -j MARK --set-mark 1

Desweiteren mldonkey auf 10 kb/s Upload beschränkt.
Ergebnis: Kaum noch Verzögerung aber periodisches (halbsekündliches) Knacken. Nicht gerade höchster Telefoniegenuss aber zur Verständigung reichts. Mitbewohner 2 konnte ungestört weiter surfen und chatten.

Ein deutlicher Fortschritt ist das also schon, aber es bleibt noch Potential für Verbesserungen.

Gruß
Johannes

 

[ypsilon]

Servus,

also das mit dem knacken kann ich bestätigen!!!
Ist bei mir genauso bei mldonkey ... aber es nervt halt schon ein wenig!
Trotzdem ein wahnsinniger Fortschritt ....

Ach ja und meine Schweser hatte natürlich auch die Schnautze voll während meines Telefonates per Sip meinte Sie das alles in Zeitlupe geht bei Ihr also scheint der Filter schon massiv zu greifen.

bye

yps

 

[cibi]

während meines Telefonates per Sip meinte Sie das alles in Zeitlupe geht bei Ihr also scheint der Filter schon massiv zu greifen.

Das knacken kann ich auch bestätigen, aber bei mir läuft neben her z.B. www (fast) ganz normal weiter.
Ich habe DSL mit 2048/192.; den max upload habe ich z.Zt. im Skript auf 176 festgelegt und den beiden Klassen 65kit (1:10) bzw 85kbit(1:11, 20ms) zugewiesen.
Falls ihr einen 128kbit Upload habt, versicht doch mal RATEUP auf einen niedrigeren Wert einzustellen (z.B. 120 oder 112) und die Werte in den Klassen dementsprechen anzupassen. (Eventuell dann den gsm Codec benutzen)
Ansonsten müsste man vielleicht doch noch ein paar Regeln hinzufügen, die z.B. http/chat vorrang vor BT einräumen.


Weiß jemand was genau der umax Wert ist? sollte der eventuel der MTU entsprechen?

 

[phone-man]

@traxanos: Kannst du etwas zu den hfsc Parametern sagen bzw. wie du auf die Werte in deinem Script gekommen bist (sc umax dmax ul)? Wenn man die Bedeutung der Parameter kennt, kann man damit auch noch etwas experimentieren.

 

[ypsilon]

Weiß jemand was genau der umax Wert ist? sollte der eventuel der MTU entsprechen?

umax : maximum unit of work

versuche gerade auch mal alles zusammenzustellen um ein wenig besser damit zu experimentieren.

SC := [ [ umax BYTE ] dmax SEC ] rate BPS

umax : maximum unit of work
dmax : maximum delay
rate : rate

bye

yps

 

[glotzi]

sipshaper automatisch nach Reconnect automatisch starten

Hallo,

ich habe einen Debian-Server (ct-Server) mit IpCop in einer Linux-UML. Ich würde den Sipshaper gerne nach der 24h reconnect bzw. nach einem manuellen Reconnect (neu) starten.

Weiß jemand, wie man den ct-IpCop dazu bringt nach einem Reconnect den sipshaper neu zu starten. Ich habe schon alle möglichen /etc/rc.d Scripte ausprobiert. Klappt einfach nicht, nach dem disconnect ist die HFSC-Queue immer weg

 

[TomCat05]

mach doch einfach folgendes, für die 24 Stunden Trennung manuell durch ein Script durch. In dieses Script schreibst du auch die Zeile zum starten das Sipshaper dann ab in die crontab un irgendwann Nachts ausführen
z.B. so
#!/bin/sh
/etc/rc.d/rc.red stop
sleep 5 #evtl auch längere Haltezeit
/etc/rc.d/rc.red start
und hier die Zeile zum starten des Sipshapers

So sollte es doch gehen .....zumindest für die 24 h Trennung....

 

[glotzi]

mach doch einfach folgendes, für die 24 Stunden Trennung manuell durch ein Script durch. In dieses Script schreibst du auch die Zeile zum starten das Sipshaper dann ab in die crontab un irgendwann Nachts ausführen
z.B. so
#!/bin/sh
/etc/rc.d/rc.red stop
sleep 5 #evtl auch längere Haltezeit
/etc/rc.d/rc.red start
und hier die Zeile zum starten des Sipshapers

So sollte es doch gehen .....zumindest für die 24 h Trennung....

Danke für den Hinweis, aber soweit war ich schon. Wenn ich manuell trenne, steh ich aber wieder genauso doof da, wie vorher.

 

[udosw]

Re: sipshaper automatisch nach Reconnect automatisch starten

@glotzi

Ich hab' zwar nicht den c't-Server, aber auch Debian.

Es geht bei mir so:
Nachts um 4:30 Uhr wird das Netzwerk "resettet"
1.) /etc/crontab:
30 04 * * * root /etc/init.d/networking restart

und dadurch auch die PPP-Verbindung kurz unterbrochen:
2.) /etc/network/interfaces
...
auto ppp0
iface ppp0 inet ppp
provider arcor

Dadurch werden folgende Dienste erst ab- ...
3.) :/etc/ppp/ip-down.d# ls -la
drwxr-xr-x 2 root root 4096 2005-04-01 21:44 .
drwxr-xr-x 7 root root 4096 2005-03-31 21:37 ..
-rwxr-xr-x 1 root root 559 2004-12-30 17:26 0000usepeerdns
-rwxr-xr-x 1 root root 171 2004-08-02 03:55 0pppstatus
-rwxr-xr-x 1 root root 41 2005-04-01 21:38 1sipshaper
-rwxr-xr-x 1 root root 40 2005-04-01 21:44 2firewall

und dann wieder angeschaltet:
4.) :/etc/ppp/ip-up.d# ls -la
drwxr-xr-x 2 root root 4096 2005-04-18 22:31 .
drwxr-xr-x 7 root root 4096 2005-03-31 21:37 ..
-rwxr-xr-x 1 root root 891 2004-12-30 17:26 0000usepeerdns
-rwxr-xr-x 1 root root 177 2005-02-22 23:33 0clampmss
-rwxr-xr-x 1 root root 160 2004-08-02 03:55 0pppstatus
-rwxr-xr-x 1 root root 41 2005-04-01 21:44 1firewall
-rwxr-xr-x 1 root root 42 2005-04-01 21:39 2sipshaper
-rwxr-xr-x 1 root root 815 2003-03-14 23:18 3ddclient
...

2sipshaper enthält hier z.B.:
#!/bin/sh

/usr/local/bin/sipshaper start


Alles klar?
Udo

 

[glotzi]

@udosw

Danke für das ausführliche Posting, aber das hilft mir nicht wirklich weiter.

Der IPCop hat im Gegensatz zu Debian keine Verzeichnisse /etc/ppp/ip-up.d und /etc/ppp/ip-down.d, sondern ein Script /etc/ppp/ip-down. Dort habe ich den sipshaper Aufruf am Ende eingetragen, allerdings ohne Erfolg. Prinzipiell ist das die gleiche Vorgehensweise, wie bei Dir.

 

[traxanos]

Ich dachte mich erinnern zu können, dass der IP Cop gar kein HFSC kann!! Der Kernel ist viel zu alt bzw hatte das passende Modul nicht. Ich kann mich natürlich irren. Und wenn er es kann, kann man mit dem Packet QoS doch die QoS Regeln so anlegen wie im SipShaper?