tc qdisc - Frage

[merlin64]

aus der debian-user-german FAQ

6.3 Latenzzeiten bei interaktiven Verbindungen verringern

Der Befehl tc qdisc add dev ppp0 root tbf rate 118kbit latency 50ms burst 1540 verbessert die Reaktionszeit bei telnet, ssh und Konsorten erheblich. Die Grenze "118kbit" ist auf Verbindungen mit 128kbit Upstream gemünzt, sprich für die meisten ADSL-Nutzer geeignet. Bei anderer Upstream-rate zieht man einfach 5-10% des maximalen Durchsatzes ab und setzt diese Zahl in den Befehl ein.

klang fand ich doch ganz interessant und nach einigem suchen fand ich dann auch das debian package in dem tc enthalten ist (iproute)
als ich (T-DSL user) dann aber diesen befehl eingab, kam bei mir nur "RTNETLINK answers: Invalid argument" als antwort...

nun wollte ich wissen, ob sich schon jemand mal mit diesem tool beschäftigt hat - ob es was bringt (online spiele - remote arbeit) und wie ich es eigentllich zu laufen bekomme.
vielleicht hat ja einer schon gute anlaufstellen parat, sonst werde ich mich mal bei gelegenheit selbst umsehen...

[pdreker]

Du musst im Kernel den Support dafür aktivieren.
make menuconfig -> Networking Options -> QoS and/or Fair Queuing

Welche Unteroptionen man da braucht, weiss ich nicht, ich habe hier einfach alle aktiviert...

Ob es was bringt? Ich meine ja, aber ich wollte hier auch ein anderes Problem lösen: Wenn mein Upstream dicht war (30K/sec), dann brach mein Downstream zusammen, weil im DSL Modem der (gesharete) Sende-/Empfangspuffer ständig mit Upstream Paketen voll war, die ja mit 10MBit/s ins Modem gestopft werden und so dann die Downstreampakete immer auf einen freien Buffer warten mussten. Mit QoS habe ich dann die maximale Datenmenge, die der Router ins Modem stopfen darf beschränkt (Bandwidth limiting), und dabei gleich noch die oben genannten Sachen gemacht.

Ergebnis: selbst wenn der Upstream "dicht" ist kann man jetzt noch schnell, und fast ohne Verzögerung surfen.

Patrick

[domo]

Ein guter Startpunkt ist das Linux Advanced Routing & Traffic Control HOWTO: http://lartc.org/howto/index.html

Wenn Du mehrere Computer an ein DSL/Cable Modem über einen Router verbindest, ist das eine extrem flexible und mächtige Möglichkeit, die Bandbreite fast nach Belieben aufzuteilen. Und endlich kann ich wieder schnell surfen !!

Ich habe vorallem mit den HTB qdisc gearbeitet, und bin sehr zufrieden. ( http://luxik.cdi.cz/~devik/qos/htb/ )

[merlin64]

also ist die einstellung im debian standardkernel (ich benutze im moment noch 2.4.18-bf2.4) nicht aktiviert, oder wie?

naja, dann werde ich mich wohl ans kompilieren begeben...

pdreker: was würdest du denn für einstellungen für tdsl (768up/128down) empfehlen? und was von dem oben geposteten script sollte ich für bessere pings übernehmen?

domo: danke - das schaut ja nach nem brocken geballter information aus
auch wenn ich noch nicht so der crack auf dem gebiet bin werd ich's mir mal ansehen, die möglichkeiten klingen ja schon toll

[pdreker]

Das, was in Deinem ersten Post stand würde für T-DSL schon passen. Deinen grundsätzlichen Ping für Netzwerkspiele wirst Du damit aber nicht deutlich verbessern können, weil der zu 95% ausserhalb Deines Netzes stattfindet, was Du nicht beeinflussen kannst.

Wenn ich von hier aus z.B. http://www.GameZone.de anpinge, dann kann man folgendes beobachten:
ping zu meinem Router: 0.4ms
ping zum Einwahlrechner in der Vermittlungsstelle: 7.0ms (das ist die Modemverzögerung)
ping zu http://www.GameZone.de: 46.3ms mit Ausreissern bis auf 140ms

Kontrollieren kann ich das Ganze (sehr bedingt) bis zum Vermittlungsrechner, indem ich an meinem Router tune, aber an den 39ms im Netz kann ich nichts machen...

Die Regel von oben führt nur dazu, dass interaktive Anwendungen, wie telnet, ssh usw. sich flüssiger anfühlen, weil man ziemlich sofort eine Reaktion auf Tastendrücke bekommt. Ausserdem wird sich der Effekt erst dann so richtig bemerkbar machen, wenn Deine Leitung unter Druck steht. Mit der Regeln sollte es möglich sein Downloads zu machen, während man zockt, ohne dass die beiden Streams sich zu sehr stören.

Magie können auch diese Dinge nicht wirken, aber es wird hart daran gearbeitet

Patrick

[glatzor]

@pdreker:
Möchtest Du mal Dein komplettes tc-Skript posten. Ich wollte dies auch mal vor einiger Zeit bei mir einrichten, bin dann aber kläglich gescheitert.

[pdreker]

Skript??? Das ist eine Zeile...

Code: Alles auswählen

tc qdisc add dev ppp0 root tbf rate 252kbit latency 30ms burst 2kb

Nothing special...

Das ist allerdings auf Q-DSL (1040 kBit/s Down, 256 kBit/s Up) und unser DSL Modem (Efficient Networks SpeedStream) getuned. Ist schon ein bisschen her, aber hier so aus dem Kopf, was das bewirkt:

Ratelimiting des Upstream auf 252 kBit/s, damit immer noch etwas Luft für Downstream ACK Pakete bleibt, Latency sagt an, wie lange ein Paket maximal in der Warteschlange sein darf, Burst gibt an wieviel Bytes an Paketen maximal in der Warteschlange sein können; wenn burst überschritten wird, dan werden Pakete evtl. intern gedropped. Das dient dazu zu verhindern, dass die internen Buffer unseres DSL Modem überlaufen und die Verbindungen unnötig gebremst werden.
Mit diesen Einstellungen ist es halt möglich einen vollen Downstream Download zu haben (ca. 134 K/s) und dabei noch zu surfen, ohne dass man es merkt, das der Downstream ausgelastet ist (beinahe: es ist natürlich langsamer, aber die Reaktionszeiten sind immer noch gut). SSH Verbindungen fühlen sich immer "fluffig" an. Bei ausgelastetem Upstream (ein klassisches DSL Problem) kann ebenfalls problemlos gesurft werden (da merkt man es gar nicht!) und auch interaktive Services sind noch gut nutzbar.
Allerdings ist das auf "Surfen/FTP und SSH" getuned und das war echt etwas "Handarbeit", die Zahlen rauszufinden. Zum tunen habe ich einen Upload mit voller Bandbreite per FTP gestartet, und eine SSH zu einem externen Rechner. Dann habe ich ausgehend von

Code: Alles auswählen

tc qdisc add dev ppp0 root tbf rate 256kbit latency 50ms burst 5kb

die Werte solange frisiert, bis ich zufrieden war. Die jetzigen Einstellungen sind allerdings etwas "zerbrechlich": andere Anwendungen (Spiele) verhalten sich anders, und erfordern etwas andere Werte, um gute Performance zu erreichen. Für komplexeres Verhalten würde ich nicht TBF sondern CBQ empfehlen, da man hier (IIRC) einzelnen Services Prioritäten zuweisen kann. Man könnte also z.B. Unreal Tournament Paketen eine eigene Latenz/garantierte Bandbreite zuweisen... Ich habe mich allerdings an das KISS Prinzip gehalten, und habe CBQ aussen vor gelassen

Literatur:
man tc
man tc_tbf
man tc_cbq

Patrick

[glatzor]

Ich hatte auch gehofft, dass Du mir was zu cbq sagen könntest.

[pdreker]

CBQ habe ich mir kurz angesehen, weil mich das Prinzip reizte, aber Pakete erst mit iptables zu markieren/klassifizieren und sie dann mit einem hierarchischen Verteiler System (CBQ) rauszusenden war mir irgendwie zu kompliziert. TBF hat's ja dann auch getan...

KISS halt...
Ansonsten: Advanced Routing Howto...

Patrick

[glatzor]

ich habe noch eine Lösung mit cbq über Google gefunden und in ein Start/Stop-Skript eingebettet. Es scheint bei mir zu funktionieren:

Alten Skript-Code dem Fetlel zu Liebe entfernt.

[merlin64]

wieviel effektiven down- und upstream hast du damit, wenn du versuchst beides auszureizen?

bleibt der download voll, und wieviel vom upstream geht verloren?

[glatzor]

Bei der oben geposteten Version handelte es sich um eine modifizierte Version des Skripts in der Advanced Routing HowTo.
Darum hier das "Original" mit Init-Skript.

Das Ergebnis ist, dass ich bei laufendem Direct Connect 12k up und 90k down habe und auch noch surfen kann.

Es muss aber nach jedem Verbindungsaufbau neu gestartet werden.

Code: Alles auswählen

#!/bin/sh
# 
# /etc/init.d/limiter
#
# The Ultimate Setup For Your Internet Connection At Home
# 
#
# Set the following values to somewhat less than your actual download
# and uplink speed. In kilobits

DOWNLINK=780
UPLINK=120
DEV=ppp0

function StartCBQ () {


###### uplink

# install root CBQ

tc qdisc add dev $DEV root handle 1: cbq avpkt 1000 bandwidth 10mbit 

# shape everything at $UPLINK speed - this prevents huge queues in your
# DSL modem which destroy latency:
# main class

tc class add dev $DEV parent 1: classid 1:1 cbq rate ${UPLINK}kbit \
	allot 1500 prio 5 bounded isolated 

# high prio class 1:10:

tc class add dev $DEV parent 1:1 classid 1:10 cbq rate ${UPLINK}kbit \
	allot 1600 prio 1 avpkt 1000

# bulk and default class 1:20 - gets slightly less traffic, 
#  and a lower priority:

tc class add dev $DEV parent 1:1 classid 1:20 cbq rate $[9*$UPLINK/10]kbit \
	allot 1600 prio 2 avpkt 1000

# both get Stochastic Fairness:
tc qdisc add dev $DEV parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev $DEV parent 1:20 handle 20: sfq perturb 10

# start filters
# TOS Minimum Delay (ssh, NOT scp) in 1:10:
tc filter add dev $DEV parent 1:0 protocol ip prio 10 u32 \
	match ip tos 0x10 0xff  flowid 1:10

# ICMP (ip protocol 1) in the interactive class 1:10 so we 
# can do measurements & impress our friends:
tc filter add dev $DEV parent 1:0 protocol ip prio 11 u32 \
	match ip protocol 1 0xff flowid 1:10

# To speed up downloads while an upload is going on, put ACK packets in
# the interactive class:

tc filter add dev $DEV parent 1: protocol ip prio 12 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

# rest is 'non-interactive' ie 'bulk' and ends up in 1:20

tc filter add dev $DEV parent 1: protocol ip prio 13 u32 \
	match ip dst 0.0.0.0/0 flowid 1:20

########## downlink #############
# slow downloads down to somewhat less than the real speed  to prevent 
# queuing at our ISP. Tune to see how high you can set it.
# ISPs tend to have *huge* queues to make sure big downloads are fast
#
#  attach ingress policer:

tc qdisc add dev $DEV handle ffff: ingress

# filter *everything* to it (0.0.0.0/0), drop everything that's
# coming in too fast:

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 10k drop flowid :1
}

function StopCBQ () {

# clean existing down- and uplink qdiscs, hide errors
#tc qdisc del dev $DEV root    2> /dev/null > /dev/null
#tc qdisc del dev $DEV ingress 2> /dev/null > /dev/null
tc qdisc del dev $DEV root    
tc qdisc del dev $DEV ingress
}

function StatusCBQ () {

tc qdisc show dev ppp0
tc class show dev ppp0
tc filter show dev ppp0

}

case "$1" in
	stop)
		StopCBQ
		;;
	
	start)
		StartCBQ
		;;

	restart)
		StopCBQ
		StartCBQ
		;;

	status)
		StatusCBQ
		;;

	*)
		echo "Usage: limiter (start|stop|restart|status)"
		;;
esac