TC unter Linux

Script...

gepeinigter_aon_neukunde — Sat, 19 Nov 2005 21:21:38 GMT

Anbei mein Script... Ich habe reingeschrieben, was man evtl. dazubraucht.
Ich stell's unter GPL - also darf es jeder weiterverwenden...


#!/bin/bash

# (c) Grünwald Michael 2005 - GPLled.
# Nach Muster aus lartc.pdf

# Benötigt wurde:
# iproute2-2.4.7-now-ss020116-try.tar.gz
# htb3.6-020525.tgz
# Getestet bei SuSE8.0, Kernel 2.4.28

# Speeds: Immer etwas geringer als die "reale" um Queues im Modem zu vermeiden
DOWNLINK=63     # ISDN: 63KBit. Modem: 50KBit.
UPLINK=63       # ISDN: 63KBit. Modem: 32KBit
DEV=ippp0       # ISDN: ippp0. Modem: ppp0

#
# Klassen
#
# THEMA         RATE    CEIL    RATE    PRIO    Garantiert      Max
#               Punkte  KBit    KBit            in Byte/sec     in Byte/sec
# HIGH-Prio     50      63      33      1       4224            8064
# ARBEIT        25      56      16      2       2048            7168
# DEFAULT       20      51      13      2       1664            6528
# FTP,MAIL      1       40      1       3       128             5120
# SUMME         93              63
#
# Selber Berechnen wie folgt:
#       - Spreadsheet anlegen
#       - Ratenpunkte Vergeben
#       - CEIL und PRIO manuell festlegen.
#       - RATE berechnet:
#         RATE_KBit(x) = RUNDEN(RATE_Punkte(x)*UPLINK/SUMME_RATE_Punkte.
# Ansatz Prio: Nur das allerwichtigste PRIO1, das allerunwichtigste PRIO3

# --- ROOT ---
ROOT_QDISC=1:
ROOT_CLASS=1:1
ROOT_DEFAULT=50         # Unklassifiziertes nach 1:50

# ---- HIGH_PRIORITY: ACK, ICMP und interacive ---
HIGH_PRIO_CLS=1:10
HIGH_PRIO_RATE=33kbit
HIGH_PRIO_CEIL=63kbit   # Hohe CEIL unnötig. Wenn hier viel landet,
                        # dann war was falsch konfiguriert.
HIGH_PRIO_PRIO=1
HIGH_PRIO_SFQ=10:

# --- ARBEIT: Wichtiger => Arbeit soll schneller fertig sein
ARBEIT_CLS=1:20
ARBEIT_RATE=16kbit
ARBEIT_CEIL=56kbit
ARBEIT_PRIO=2
ARBEIT_SFQ=20:

# --- DEFAULT: Alles unklassifizierte ---
DEFAULT_CLS=1:50
DEFAULT_RATE=13kbit
DEFAULT_CEIL=51kbit
DEFAULT_PRIO=2
DEFAULT_SFQ=50:

# --- MAIL: So langsam wie geht... Hier sparen wir Performance, die wir bei
# priorisierten Diensten gewinnen
MAIL_CLS=1:70
MAIL_RATE=1kbit
MAIL_CEIL=40kbit
MAIL_PRIO=3
MAIL_SFQ=70:

# Verkehr zu welchen Servern kommt in die Arbeitsklasse (priorisiert)
SRV1=1.2.3.4  # EGAL
SRV2=131.130.252.18             # UniVPN

#
# ___ENDE CONFIG___

# Alte Qdiscs löschen
tc qdisc del dev $DEV root    2> /dev/null > /dev/null
tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null

#
# Wird in /etc/init.d/rc3.d eingehängt (nach ipppd).
# Bei "start" als Parameter - Definiere. Bei anderen anderen - lösche
if [ "$1" != "start" ]
then
        exit
fi

###### uplink

# root-htb: htb - IMHO die beste QDisc. Unqualifizierter Verkehr nach DEFAULT
tc qdisc add dev $DEV root handle $ROOT_QDISC htb default $ROOT_DEFAULT

# Alles nach $UPLINK-Speed shapen. Wir dürfen keine Queues im Modem erzeugen..
# denn dann hätten wir keine Shape-Möglichkeit mehr - und schlimme Latenzzeiten
tc class add dev $DEV parent $ROOT_QDISC classid $ROOT_CLASS \
        htb rate ${UPLINK}kbit

# Klassen nach Definition anlegen
tc class add dev $DEV parent $ROOT_CLASS classid $HIGH_PRIO_CLS htb \
        rate $HIGH_PRIO_RATE ceil $HIGH_PRIO_CEIL prio $HIGH_PRIO_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $ARBEIT_CLS htb \
        rate $ARBEIT_RATE ceil $ARBEIT_CEIL prio $ARBEIT_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $DEFAULT_CLS htb \
        rate $DEFAULT_RATE ceil $DEFAULT_CEIL prio $DEFAULT_PRIO
tc class add dev $DEV parent $ROOT_CLASS classid $MAIL_CLS htb \
        rate $MAIL_RATE ceil $MAIL_CEIL prio $MAIL_PRIO

# All Bekommen  Stochastic Fairness Queueing:
tc qdisc add dev $DEV parent $HIGH_PRIO_CLS handle $HIGH_PRIO_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $ARBEIT_CLS handle $ARBEIT_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $DEFAULT_CLS handle $DEFAULT_SFQ sfq perturb 10
tc qdisc add dev $DEV parent $MAIL_CLS handle $MAIL_SFQ sfq perturb 10

#
# Filter-Regeln: Welcher Verkehr kommt in welche Klasse ?
#

# ICMP (ip protocol 1) Kommt in die höchste Klasse...
# Für Messungen und Eindruck schinden bei PING ;-)

tc filter add dev $DEV parent 1:0 protocol ip prio 1 u32 \
        match ip protocol 1 0xff flowid 1:10

# Um Downloads zu beschleunigen wärend wir uploaden kommt ACK in die höchste
tc filter add dev $DEV parent 1: protocol ip prio 1 u32 \
   match ip protocol 6 0xff \
   match u8 0x05 0x0f at 0 \
   match u16 0x0000 0xffc0 at 2 \
   match u8 0x10 0xff at 33 \
   flowid 1:10

# TOS Minimum Delay (ssh, NICHT scp): Nur wenn nicht in anderer Queue erledigt
# Komme auch in höchste Queue.
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 10 u32 \
      match ip tos 0x10 0xff  flowid $HIGH_PRIO_CLS

# Arbeitsserver in die zweite Klasse
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 2 u32 \
   match ip dst $SRV1 flowid $ARBEIT_CLS
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 2 u32 \
   match ip dst $SRV2 flowid $ARBEIT_CLS

# Mail ganz nach hinten
# SMTP
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 25 0xffff flowid $MAIL_CLS
# POP2
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 109 0xffff flowid $MAIL_CLS
# POP3
tc filter add dev $DEV parent $ROOT_QDISC protocol ip prio 1 u32 \
   match ip dport 110 0xffff flowid $MAIL_CLS

#
# Rest landet in DEFAULT-QUEUE


########## downlink #############

# Downlink shapen, damit wir der Engpaß sind (und nicht der ISP)
tc qdisc add dev $DEV handle ffff: ingress

# *ALLES* filtern (0.0.0.0/0), alles Wegwerfen, was zu schnell kommt

tc filter add dev $DEV parent ffff: protocol ip prio 50 u32 match ip src \
   0.0.0.0/0 police rate ${DOWNLINK}kbit burst 3K drop flowid :1

Re(4): TC unter Linux

gepeinigter_aon_neukunde — Thu, 17 Nov 2005 10:05:27 GMT

Natürlich krieg ich kein richtiges QoS hin mit der Bandbreite und ohne eingriff beim Provider...

Ach ja, noch eine blöde Frage:

ISDN bekommt bei mir default MTU (ich vermute im Rahmen der chap-Anmeldung) von 1500 - also dasselbe wie bei ethernet.

Aus dem Bauch raus kommt mir eine MTU von 1500 bei 64KBit extrem hoch vor...

Meine Überlegung war wie folgt:
Die kleinsten MTU's die ich gesehen habe, waren bei AFAIK 536 (Modems vor langer Zeit)... Also könnte es ja Sinn machen, wenn ich die MTU auf viel. 768 reduziere ? Natürlich steigt dann mein Netzwerk-Overhead bei größeren Paketen an - andererseits könnte ich ja doch Interaktivität gewinnen.

Meine größte Sorge dabei ist, daß diverse Clients (Windows) ziemlich sicher bei ihren Paketen das "Don't Fragment"-Bit setzen... Und evtl. keine gute PMTU-Discovery machen.

Ich könnte also:
1.) Bei den Clients fix eine MTU von 768 eintragen - ungut weil Papi's rechner
2.) via iptables folgende Regel bauen:
- wenn ein Paket von eth0 kommt
- und das DF-Bit gesetzt hat
- dann lösche /PREROUTING/ das DF-Bit - und füge es /POSTROUTING/ wieder an
3.) Auf MTU-Modifikationen wegen möglicher Probleme verzichten - und stattdessen via iptables fix postroutung auf ippp0 bei SYN-Paketen eine MSS von 768 anbieten.

Wenn ich es richtig verstanden habe, würde mir dann die Gegenstelle - auf tcp-Verbindungen [udp kann ich mal ignorieren, da kommt bei mir nix so großes her] - nie mehr als 768 bytes auf einmal senden - so als ob ich die MTU gesetzt hätte... Nun denn, dann wird's aber auch nicht gegen das DF-Bit helfen, oder ?

ARGH!
Vor ewigkeiten hab' ich mich mal mit MTU's herumgespielt (wg. TR und ETH im selben Netz)... Dunkel erinner ich mich, daß das die Hölle war... Was huhn ?

Re(3): TC unter Linux

mIstA — Thu, 17 Nov 2005 09:22:43 GMT

Besser sei es aber, wenn man egress (bei mir eth) wieder shaped.

Jup, stimmt - das sollte das Problem durch das Verwerfen bereits durch die Engstelle übertragener Pakete entschärfen.

Trotzdem bleibt (vor allem falls der Provider für Dich ankommende Daten buffert) vermutlich das Problem bei vielen relativ kurzen Verbindungen (wie z.B. beim Surfen), daß die Drosselung eben erst mit Verzögerung eintritt.

Wenn's jemand interessiert, kann ich meine Config-Scripts dann posten.

Interessant wärs auf jeden Fall (auch wenn ich für mich derzeit keine konkrete Anwendung sehe) - vor allem nachdems für das Problem ja offenbar im Netz noch nicht allzuviel an Lösungen zu geben scheint.

Re: Ach ja, eine iptables-DAU-Frage habe ich noch:

mIstA — Thu, 17 Nov 2005 08:53:47 GMT

Bzgl. IPtables weiß ichs net, aber IPfilter scheints offenbar zu können; zumindest hab ich bei meiner Router-SW (http://m0n0.ch/wall - ist allerdings auf FreeBSD/IPfilter Basis) eine entsprechende Einstellungsmöglichkeit Mask sowohl für Pipes als auch für Queues, die scheinbar genau das ermöglicht - die Beschreibung dazu:
If 'source' or 'destination' is chosen, a dynamic pipe with the bandwidth, delay, packet loss and queue size given above will be created for each source/destination IP address encountered, respectively. This makes it possible to easily specify bandwidth limits per host.

Re(2): TC unter Linux

gepeinigter_aon_neukunde — Thu, 17 Nov 2005 08:46:29 GMT

Hi !

Das war mir eh klar, daß ich auf meiner Seite nur sehr eingeschränkte Möglichkeiten habe...

Inzwischen bin ich weiter:
Uploadseitig greift meine Methode mal... Das bedeutet, daß lange uploads meine ACKs nicht mehr blockieren können und daher paralleles Arbeiten besser klappt - sichtbar besser.

Für die Andere Richtung habe ich im INet folgende Empfehlung getroffen:
Man könnte ja ingress (bei mir ISDN) policen - also gezielt Pakete wegwerfen, um so die gegenüber zum drosseln zu bewegen... Besser sei es aber, wenn man egress (bei mir eth) wieder shaped. Das würde bedeuten, daß ich per QoS wieder gezielte priorisiere - und Bulk-ftp-traffic weniger bandbreite kommt (außer es gibt sonst keinen Traffic). Das hat zur Folge, daß man wieder alle QoS-Mechanismen zur Verfügung hat - wenn auch indirekter... Werde ich am Wochenende angehen.

Wenn's jemand interessiert, kann ich meine Config-Scripts dann posten.

Re: TC unter Linux

mIstA — Thu, 17 Nov 2005 08:26:33 GMT

Dadurch müßten die Downloads "außerhalb" der "ArbeitsIPs" langsamer kommen -weil sie seltener ACKs bekommen und daher drosseln müßten.

Allerdings wird die Priorisierung nur dann greifen, wenn Dein Upstream überlastet oder zumindest an der Auslastungsgrenze arbeitet, denk ich.

Was eventuell klapen könnte, wäre den Downstream (also konkret die Bandbreite die Du in Dein LAN rein eralubst) für alle nicht-priorisierten Verbindungen drosselst; allerdings geht das vermutlich nur statisch, also unabhängig davon, obs im Moment überhaupt aktive Verbindungen gibt, die Priorität haben sollen - außer indem Du die Drosselung immer von Hand (de)aktivierst.

Ein wesentlicher Nachteil dieses Ansatz ist aber leider, daß damit letztlich bewußt Pakete verworfen werden, die bereits über die (ohnehin überlastete) ISDN-Leitung übertragen wurden. Das wird vermutlich vor allem dann zum Problem werden, wenn die jeweilige Verbindung nicht lang genug besteht, daß sich der Server auf die niedrige Geschwindigkeit einregeln kann. Zusätzliche Probleme könnts eventuell auch durch einen providerseitigen Buffer geben.

Jadenfalls kannst ja ohne Probleme testen, ob bestimmte Shaping-Regeln was bringen; einfach den Downstream mit einem Download blockieren und schauen obs für die interaktiven Verbindungen was bringt.

Aber wirklich effizient kannst eine Priorisierung für Deinen Downstram (wahrscheinlich) nur auf der sendenden Seite - also beim Provider; vielleicht gibts ja einen Provider, der das zumindest auf Anfrage als Service anbieten kann.

Re(9): TC unter Linux

patos — Mon, 14 Nov 2005 20:53:29 GMT

achso. das schon. aber in der maschine regelt bits die geschwindigkeit herunter sobald die verbindung gebraucht wird.

ist klar dass bits nicht wissen kann dass eine andere machine ein gateway beansprucht...

Re(8): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 20:50:37 GMT

?
Wenn mein Rechner aus dem WLAN meint, windows update auszulösen... Dann kommt ja der ganze Verkehr auf meinem Server zusammen - also der soll man runterdrosseln, dachte ich.

Re(7): TC unter Linux

patos — Mon, 14 Nov 2005 20:20:09 GMT

Naja, windows-update könnte man gaaanz langsam im Hintergrund machen.

das macht bits von alleine, da brauchst du kein qos.

Re(5): TC unter Linux

patos — Mon, 14 Nov 2005 20:18:35 GMT

jetzt stell dir vor was passiert wenn du mit höhere priorität die leidung über 2 sek vollständig belegst...

die andere seite die wartet verwirft die pakete und fragt nochtmal danach. das kannst du gar nicht verhindern. mit prioititäten zu arbeiten heisst in ausnahmefall retransmits dulden.

das passiert aber so transparent dass du es gar nicht merkst. ich könnte nicht sagen ob jetzt die verbindung langsam ist weil eine gegenstelle ein retransmit aufgefordert hat oder ob das qos den verkehr abbremst.

eines ist bei mir aber klar. wer die priorität braucht bekommt sie auf meiner leitung. mein voip telefon kennt selbst bei extremen belastungen keine aussetzer. ob die anderen das eine oder andere paket wiederholen müssen ist mir wurst, da auch das wiederholte paket sich den regeln des qos zu unterwerfen hat.

Re(6): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 20:09:45 GMT

Eben nicht... dann kommen die ACKs ja noch schneller durch den TCP/IP-Stack auf die 64kBit-Leitung - dann wird's noch langsamer

Re(5): TC unter Linux

MidiFan — Mon, 14 Nov 2005 20:04:39 GMT

Wenn ein durchschnittspaket (insbesondere, wenn dabei auch ssh rennt, die ja
wie telnet klein sind) so kommen die ACK's um 0.1 bis 0.2 Sekunden später auf
die Leitung... Dadurch dauert tendenziell jedes Window eben um 0.1-0.2
Sekunden länger (vermutet der DAU) - was

kauf dir besser einen pc mit mehr leistung...dann geht der seitenaufbau auch um 0.1 oder 0.2 schneller

Re(8): TC unter Linux

MidiFan — Mon, 14 Nov 2005 20:03:07 GMT

ich mein wenn diese zahlen nicht dafür sprechen...was den sonst

Re(7): TC unter Linux

MidiFan — Mon, 14 Nov 2005 20:00:31 GMT

Naja, windows-update könnte man gaaanz langsam im Hintergrund machen.

mache ich nicht per inet.

Evtl. mail (wenn dir ein jolly wieder mal einen riesigen Anhang schickt oder
wieder Viren die Runde machen)

is mir egal da ich thunderbird ein limit von 500kb/mail eingestellt habe...schickt mir jemand was größeres schaue ich zuerst per webmail nach dem rechten.

glaub mir. bei 1 Mbit brauche ich sowas nicht als single user.

Re(7): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 19:30:37 GMT

Außerdem bin ich sicher, daß man in das Thema nur 200-300 Stunden stecken muß, um sich nachher ganze 10 millisekunden oder so zu ersparen - also wenn nicht alleine diese Zahlen dafür sprechen

Re(6): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 19:29:48 GMT

Naja, windows-update könnte man gaaanz langsam im Hintergrund machen.
Evtl. mail (wenn dir ein jolly wieder mal einen riesigen Anhang schickt oder wieder Viren die Runde machen) auch langsamer - damit die "Arbeitsrate" immer top ist.

Re(4): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 19:27:22 GMT

Ich will sie ja nicht unendlich warten lassen...
sondern nur eben, bis nix anderes von mir up geht.
Das verschiebt sich also wohl auf der Zeitachse um 1-3 Pakete.

Wenn ein durchschnittspaket (insbesondere, wenn dabei auch ssh rennt, die ja wie telnet klein sind) so kommen die ACK's um 0.1 bis 0.2 Sekunden später auf die Leitung... Dadurch dauert tendenziell jedes Window eben um 0.1-0.2 Sekunden länger (vermutet der DAU) - was bei 8KByte max. downstream ja doch hilfreicher ist, bulk zu glätten.

Daher sollte das ergebnis - gerade bei interaktiven Sessions, wo man ja doch rtt's von <0.2 sekunden will, durchaus durchschlagen könnte... und gleichzeitig wäre die Zeitspanne klein genug, daß wohl kaum ein Timeout passieren würde...

Ist das so abwegig/utopisch/blauäugig ?

Re(5): TC unter Linux

MidiFan — Mon, 14 Nov 2005 19:24:30 GMT

habe genau 0 filesharing software auf meinem pc...ausser vielleicht die Datei und Druckfreigabe zu meinem 2 Pc...aber ob es sich auszahlt dort prioritäten zu setzen..

Re(3): TC unter Linux

patos — Mon, 14 Nov 2005 19:20:51 GMT

BTW, wie priorisiert der WRT die denn ? priorisying via wegschmeißen ? Meine
Lösung hätte im Ansatz kein einziges Packerl weggeworfen - daher keine
retransmits ausgelöst..

keine ahnug... was bringt das aber? du kannst die gegenstelle nicht unendlich warten lassen, die retransmits werden von der gegenstelle gesteuert.

Meine Idee ist aber, sie [außer bei den ArbeitsIPs] /schlechtestens/ zu
priorisieren..

habe ich auch mit meiner mulimaschnine.

Re(2): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 19:16:16 GMT

Meine Idee ist aber, sie [außer bei den ArbeitsIPs] /schlechtestens/ zu priorisieren... Damit die nicht-arbeits-Sachen automatisch später ACK's senden, dadurch die Sendenden Server ihre upload-Speed senken - und ich dadurch meine klumpat-64KBit-Download-Leitung mehr für Arbeit/interaktiv freihalte.

BTW, wie priorisiert der WRT die denn ? priorisying via wegschmeißen ? Meine Lösung hätte im Ansatz kein einziges Packerl weggeworfen - daher keine retransmits ausgelöst...

Re: TC unter Linux

patos — Mon, 14 Nov 2005 19:10:54 GMT

das mache ich über den WRT54G mit einer grafischen oberfläche ganz simpel.

SYN/ACK werden von Haus aus hochpriorisiert, da musst du nur sagen welche ips/dienste zu priorisieren sind.

Re(4): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 19:05:53 GMT

Könnt sich ja auch bei "single"-PC's auszahlen...
Denn du willst ja weiter fein Geizhalseln oder interaktive sessions offen haben, wärend du als MidiFan Terrabytes an [freier] Musik downloadest

Ach ja, eine iptables-DAU-Frage habe ich noch:

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 18:58:12 GMT

Gibt es eine möglichkeit, Pakete /gemeinsam/ zu taggen ?

Wenn pappi im Lan wieder mal mit leechget saugt, so nimmt er ja nur mir bandbreite weg - denn die 64kbit schafft eh der popeligste Server zu mir .

Die idee wäre also eine iptable-regel, die quasi-gleichzeitige verbindungen mit gleicher dest-ip und dest-port mit was anderem tagged - damit die automatisch in die allerallerlangsamste queue kommen... Anders kann man ja papis kaum erziehen

Ach ja, ergänzende noob-Frage:

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 18:56:00 GMT

So ganz klar ist mir die Thematik mit dem burst- und cburst-Parameter noch nicht... Wie setzt man den sinnvollst ein ? Und... welches ist die empfehlenswerte leafnode-Classless-qdisc ? Stochastic Fairness Queueing kommt mir idealst vor - nur wann nimmt man die anderen ???

Re(3): TC unter Linux

MidiFan — Mon, 14 Nov 2005 18:53:34 GMT

Nein. Bei mir gibts nur einen PC der im Internet hängt...es besteht also keine notwendigkeit.
aber einen versuch ist dein Ansatz auf jedenfall wert

Re(2): TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 18:52:03 GMT

Hast du das also auch so gelöst ?

Re: TC unter Linux

MidiFan — Mon, 14 Nov 2005 18:51:22 GMT

Klingt ganz plausibel

TC unter Linux

gepeinigter_aon_neukunde — Mon, 14 Nov 2005 18:48:53 GMT

Hi, Folks!

Heute bin mal ich mit Fragen dran.... Wie einige wissen, habe ich im Haus 64KBit-ISDN, und mehrere parallel arbeitende PC's... Und nein, es /gibt/ einfach nix schnelleres in meiner Ortschaft 30km von Wien (außer Sat up- und down, und das ist mir mit 1GB p.m. zu teuer, außerdem ist die Latenzzeit wohl schlimmer als bei ISDN ).

Mir schwebt jetzt folgendes vor:
tc einzusetzen um zu priorisieren... Nachdem ISDN ja 64bit up- und down hat (und ich up keinen Streß habe), hatte ich folgende Idee:

HTB qdisc einsetzen (scheint mir simpel und clever) um mal outgoing grob wie folgt zu konfigurieren:

tc qdisc add dev ippp0 root handle 1: htb default 30

Maximale Priorität für Interaktiv(ssh)

tc class add dev ippp0 parent 1: classid 1:10 htb rate 50 kbit ceil 64kbit priority 10

Mittlere Priorität für Arbeitsserver-https und POP-Arbeit

tc class add dev ippp0 parent 1: classid 1:20 htb rate 12 kbit ceil 64kbit priority 10

tc class add dev ippp0 parent 1:20 classid 1:21 htb rate 11 kbit ceil 64kbit

tc class add dev ippp0 parent 1:20 classid 1:22 htb rate 1 kbit ceil 64kbit

normale Priorität für rest

tc qdisc add dev ippp0 parent 1: classid 1:30 htb rate 1 kbit ceil 64kbit priority 10

Die schlechteste Priorität - nur wenn NIX anderes upstream anliegt - Erklärung folgt

tc qdisc add dev ippp0 parent 1: classid 1:50 htb rate 1 kbit ceil 64kbit priority 50

Dann hätte ich
alles mit dport ssh in 1:10 gelegt,
alles mit https zum Arbeitsserver in die 1:21,
ssh zum Arbeitsserver und pop/smtp zu Arbeitsmailserver in 1:22
und der Rest würde in 1:30 kommen.

Nachdem ich ja Probs downstream habe, war die Idee wie folgt:
Bei denen, die Asynchron sind, findet man öfters die Empfehlung, daß sie die SYN/ACK und ACK höchst priorisieren, damit sie i.d.F. ihren Downstream immer voll bekommen. Meine Idee war nun, alle
ACKs, die nicht zum Arbeitsserver oder den Mail-Servern gehen, automatisch via iptables getagged werden - und dann in die allerletzte Queue kommen. Dadurch müßten die Downloads "außerhalb" der "ArbeitsIPs" langsamer kommen - weil sie seltener ACKs bekommen und daher drosseln müßten.

Ist das eine verfolgbare Idee, oder stellt sich klein-gepeinigter_aon_neukunde wieder mal alles zu einfach vor ?