# tc stürtzt ab

## Freiburg

Hi, 

immer wenn ich versuche eine pfifo_fast qdisc einzufügen schreib mir tc einen segfault ins log. Hat irgendwer die selben Probleme oder ähnliche Probleme?

Jens

----------

## kopfsalat

Ist pfifo_fast nicht ohnehin die Standard-qdisc? Wenn nicht mußt Du wohl "Advanced Router" im Kernel aktivieren. 

Ich denke pfifo_fast ist nicht mittels tc konfigurierbar. txqueuelen und die TOS-Bits kann man mit ifconfig bzw. ip setzen aber damit betrittst Du einen steinigen Pfad.

Ich weiss nicht was Du genau bezwecken willst, aber prio ist wesentlich einfacher einzurichten, der geringfügige Performanceverlust steht meines Erachtens in keinem Verhältnis zum Aufwand.

Ist jedoch schon eine Weile her, daß ich mich mit traffic shaping befasst habe und das auch nur in geringem Umfang.

----------

## Freiburg

Ich wollte die pfifo_fast im htb benutzen...

----------

## kopfsalat

Schätze, wenn Du keine qdisc in die leafnodes von htb hängst ist pfifo_fast der Standard für diesen Zweig.

Sind innerhalb einer Klasse viele gleichrangige Verbindungen zu erwarten empfiehlt sich jedoch ein Dahinterschalten von sfq um zu verhindern, daß eine Verbindung die anderen erstickt, z.B. bei ftp, http usw.

----------

## Freiburg

```
qdisc htb 1: r2q 10 default 30 direct_packets_stat 0

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

 rate 0bit 0pps backlog 0b 0p requeues 0

```

ist die Ausgabe von

```
tc -s qdisc ls dev eth1
```

nachdem ich nur

```
tc qdisc add dev eth1 root handle 1: htb default 30

tc class add dev eth1 parent 1: classid 1:1 htb rate 6mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:10 htb rate 5mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:20 htb rate 3mbit ceil 6mbit burst 15k

tc class add dev eth1 parent 1:1 classid 1:30 htb rate 1kbit ceil 6mbit burst 15k
```

eingegeben habe (ist direkt von lartc)

```

qdisc htb 1: r2q 10 default 30 direct_packets_stat 0

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

 rate 0bit 0pps backlog 0b 0p requeues 0

qdisc sfq 10: parent 1:10

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

 rate 0bit 0pps backlog 0b 0p requeues 0

qdisc sfq 20: parent 1:20

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

 rate 0bit 0pps backlog 0b 0p requeues 0

qdisc sfq 30: parent 1:30

 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)

 rate 0bit 0pps backlog 0b 0p requeues 0

```

ist der Output, wenn man noch

```
tc qdisc add dev eth1 parent 1:10 handle 10: sfq perturb 10

tc qdisc add dev eth1 parent 1:20 handle 20: sfq perturb 10

tc qdisc add dev eth1 parent 1:30 handle 30: sfq perturb 10

```

hinzufügt, sieht also nicht so als ob automatisch ein pfifo_fast angelegt wird, eher nur ein fifo.

Das mit sfq ist klar, es geht aber nur darum zu verhindern das in einem Netzwerk jeder eine Mindestbandbreite bekommt, und morgen nicht alle vor meiner Türe stehen weil ihr VOIP nicht vernünftig funktioniert (daher pfifo_fast)...

----------

## kopfsalat

Ja, sieht so aus als ersetzt sfq pfifo_fast. Aber die erste Ausgabe sieht mir schon so aus als ob die Standard qdisc benutzt wird. Also, musst Du eine Klasse für bevorzugten Traffic reservieren - ohne sfq - und die sfq qdiscs nur für den weniger bevorzugten Verkehr benutzen. Am besten mit einer prio qdisc verteilen. Oder habe ich etwas mißverstanden? 

QOS für VOIP zu realisieren ist wahrlich nicht trivial. Der Schwerpunkt bei der meisten qdiscs liegt eindeutig auf der Verteilung von Bandbreite, nicht auf der Sicherstellung geringer Latenz. Allzuviel kann ich dazu fürchte ich nicht beitragen, so intuitiv würde ich sagen, daß eine htb-Konfiguration nur mäßige Resultate liefern wird - die Bandbreite wird zwar fair verteilt aber die Qualität der Verbindung ist nicht gewährleistet. Einige Downloads sind wohl drin, doch man stelle sich vor jemand schmeisst den Esel an oder treibt ähnlichen Unfug.

Ich habe mal irgendwo gelesen, daß hfsc niedrige Latenz garantieren kann und gute Resutate mit VOIP liefert.

Somit gebe ich den Ball gerne an jemanden weiter der ein zufriedenstellendes QOS für VOIP realisiert hat. Würde mich nämlich auch interessieren.

----------

## Freiburg

Hmm der Esel macht hier garnix  :Wink: 

Und das Verteilen muß halt sein, da jeder für die Verbindung zahlt. Das passende TOS-Bit zu setzen ist kein Problem, allerdings würde ich das gerne mal machen ohne das tc einen fehler der Form

```
tc[31090]: segfault at 0000000000000000 rip 0000000000000000 rsp 00007fffff89e298 error 14
```

rausschmeißt...

----------

## kopfsalat

Wie gesagt, pfifo läßt sich nicht mittels tc konfigurieren. Das Verhalten des Fifos lässt sich nur auf einer tieferen Ebene mittels z.B. ip steuern indem man bestimmten sockets andere TOS-Werte zuweist. Einfacher ist es eine prio qdisc einzufügen. Auf diese kannst Du dann einen TOS Filter setzen. Die shaper sorgen dann dafür, daß keine Verbindung die anderen verdrängt.  Ich habe leider gerade kein Beispiel zur Hand, daran würde es wohl deutlicher werden.

----------

## kopfsalat

Nachtrag - ohne Garantie auf Funktionstüchtigkeit - ich habe hier kein traffic shaping installiert:

```

# Weil nur 2 Bänder definiert werden, muss priomap spezifiziert werden. Alles landet standardmäßig auf Band 1.

tc qdisc add dev eth0 root handle 1: prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

tc qdisc add dev eth0 parent 1:1 handle 10: pfifo

tc qdisc add dev eth0 parent 1:2 handle 20: htb

#voip wobei XY der TOS Wert -> Band 0

tc filter add dev eth0 parent 1: prio 1 protocol ip u32 match ip tos 0xXY 0xff flowid 1:1

#restlicher Traffic -> Band 1, wird über htb geformt 

tc filter add dev eth0 parent 1: prio 2 protocol ip u32 match ip src 0.0.0.0/0 flowid 1:2

```

Der htb-Kram fehlt natürlich. Soll auch wirklich nur verdeutlichen was ich meinte.

----------

## Freiburg

Mir ist schon klar was du meinst  :Wink:  Der Punkte ist das es möglich sein sollte, bzw das es sich um ein Bug handelt meiner Meinung nach. Und ich hab kein Bokc irgendwann wieder von diesem Bug "gebissen" zu werden

----------

## kopfsalat

Das tc abstürzt anstatt eine ordentliche Fehlermeldung auszuspucken ist ein Bug, da bin ich mit Dir völlig einer Meinung. Das man mit einer pfifo_fast qdisc über die TOS-Bits filtern kann würde mich hingegen überraschen insofern kann ich Deine Erwartungshaltung nicht ganz nachvollziehen  :Surprised: 

So wie ich das verstehe lädt tc nur die entsprechende Bibliothek für die qdisc und reicht die Parameter an diese weiter, die wiederum das Kernelmodul konfiguriert. Da aber keine Schnittstelle für pfifo_fast existiert scheitert das. Kannst ja mal ein strace auf das Kommando ausführen, um zu sehen wo es hakt.

Wenn Du pfifo_fast benutzt verlässt Du dich halt darauf, daß die TOS Bits von der Anwendung sinnvoll gesetzt werden. Hängst Du eine prio qdisc ohne weitere Parameter ein, kriegst Du eine qdisc die genau das gleiche Verhalten aufweist wie pfifo_fast - drei Bänder mit dem TOS-Mapping von pfifo_fast. Das Mapping findest Du in der manpage von tc-prio. Soweit ich weiß ist prio etwas langsamer als pfifo_fast bzw. erzeugt mehr CPU-Last.

Anstatt prio zu konfigurieren, könntest Du die TOS Bits auch mit iptables setzen, um den Verkehr auf das gewünschte Band zu heben, so z.B.:

```

iptables -A OUTPUT -t mangle -p tcp --dport ftp  -j TOS --set-tos Minimize-Delay

```

Kurzum:

Es gibt durchaus verschiedene Möglichkeiten über TOS zu regulieren, einen Filter über pfifo_fast zu setzen ist jedoch  keine. Bin aber gespannt, wie Du das Problem löst und insbesondere wie gut es mit VOIP klappt - dann probiere ich das nämlich hier auch mal aus  :Wink: 

----------

## JSheridan

ich hoffe das ist jetzt nich zu sehr am topic vorbei, aber ich poste es trotzdem mal hier rein  :Smile: 

also leider habe ich nicht so übermäßig viel ahnung von der materie (noch nicht, habe erst angefangen mich damit zu beschäftigen), aber ich habe hier z.b. folgende situation:

ein s-dsl anschluss der verteilt wird auf 2 häuser und insgesamt 4 rechner versorgt. jeweils 2 pro haus.

ich arbeite daran eine vernünftige bandbreitenaufteilung zu bekommen. so das folgendes gewähleistet wird:

jedes haus hat die gleiche bandbreite, aber falls ein haus keinen traffic verusacht sollte das andere haus die maximale bandbreite bekommen.

in jedem haus sollte jeder pc die gleiche bandbreite bekommen.

für den upload ist dies ja sehr einfach erledigt. aber für den download ist das ja nur schwer zu begrenzen wenn ich mich da jetzt nicht irre. ich kann beim download ja nur die packete verzögern die schon angekommen sind und nach dem routing den server verlassen. sprich ich kann logischerweise ja nicht die packete verzögern die mir vom server über den isp zugeschickt werden. das heißt dann soviel das wenn z.b. einer in haus 2 online spielt (z.b. BF2 oder was auch immer) und ein oder 2 andere pcs dazu surfen es zu lags kommt wenn man die web-bandbreite während battlefield2 aktiv ist nicht drastisch drosselt.

z.b. braucht BF2 etwa 13kb downstream. bei einer 512kbit leitung ist das sogesehen relativ wenig, trotzdem muss man damit es nicht dauernd zu schlimmeren lags kommt, die restliche bandbreite aller anderen auf 256kbit begrenzen. zumindest ist das bei mir bisher der fall. spielereien wie bursts sind bei mir deaktiviert.... ein online-shooter und bursts.... die mögen sich halt nicht  :Wink: 

bei mir stellte sich jetzt halt das problem wie ich es hinbekomme das ich möglichst effizient meine bandbreite aufteilen kann ohne dabei etwas zu verschwenden.  aus verzweiflung arbeite ich deshalb an einem kleinen programm das packete logt, erkennt, eine kleine statistik führt und dadurch bestimmte applikationen wie z.b. spiele erkennt und falls diese tätig sind die regeln für tc "anpasst" um für die entsprechende person ein lag-freies spielen zu ermöglichen. erstaunlicherweise funktioniert das sogar sehr gut *g* nur wie gesagt kenne ich mich nicht sehr gut mit der materie aus. (verwende gentoo erst seit kurzem und hatte zuvor noch keinen rechner mit linux am laufen, sogsehen bin ich linux-noob).

Wie würdet ihr euer tc konfigurieren wenn ihr z.b. 3 kategorien (spiele,web,p2p) haben wolltet?

bisher verwende ich htb:

- hohe prio für spiele

- dazu eine klasse restbandbreite

- diese teilt sich in web und p2p welche sich dann jeweils auf die häuser und pcs aufteilt

im zusammenhang mit meinem kleinen progrämmchen wollte ich jetzt versuchen das ganze zu verbessern.

wo könnte ich anfangen bzw. wie würdet ihr das lösen so das ich für spiele die minimalste verzögerung der packete bekomme, aber trotzdem dabei noch soviel bandbreite wie möglich nutzen kann. gibt es eigentlich ein programm das tc dynamisch nach aktuellem traffic anpasst oder muss ich mich muss ich doch an meinem proggie weiter basteln?

bin für jeden tip dankbar  :Smile:  (schon im vorraus danke *g*)

----------

## Freiburg

Bin Momentan noch am überlegen, da VOIP eigentlich kein primäres Anwendungsgebiet ist, ich poste aber auf jeden Fall mal was ich gemach habe

----------

