Qos mit WRT54-G und WRT-DD

[joaho]

Hallo zusammen!

Qos-Fazit hier aus dem Forum: funktioniert absolut easy, solange man fett genug angebunden ist, so ab 3400/512. Sobald es aber etwas enger wird, fangen die Probleme an. Es wurde deshalb schon der Verdacht geäußert, daß es garnicht funktioniert, schließlich ist es bei 3400/512 keine Kunst, wenn zwei Sachen zusammen laufen...

Auf der Suche nach dem Qos-Gral habe ich jetzt die WRT-DD draufgetan. Sieht wirklich sehr gut aus, bisher die meisten Einstellmöglichkeiten, fast zu viele, bin ja auch Newbee. Qos hat erstmal nicht funktioniert.

Also hab ich Brainslayer, von dem die DD ist, nach mehr Doku/Info zu den Qos-Einstellungen gefragt. Er hat schnell und ausführlich geantwortet.
Ich fand es aber nicht gut, daß er sich die Zeit nimmt, und nur ich hab was davon. Deshalb habe ich Brainslayer hierher eingeladen, er ist einverstanden, wir machen das jetzt hier für alle.

Meine Daten: M-Net 1024/128, WRT-54G V2.0, WRT-DD 21b
Mein Problem: Counterstrike hängt, wenn am anderen Rechner jemand surft. Ist zwar (noch) nicht VOIP, aber CS braucht max. 6KB/s in beiden Richtungen, und wenn das schon klemmt, wie soll dann VOIP mit 10 KB gehen?

Zum Einstieg erst mal die zwei Mails, die Brain mir geschickt hat.

 

[joaho]

Von Brainslayer:

Generell ist eine ADSL leitung von den latenzzeiten nicht gerade sehr
geeignet verschiedene services wie VOIP oder CS zu mischen. Dank der
rückständigkeit der Telekom geht das leider nicht. QOS bringt vor allem bei
bandbreitenproblemen etwas. Gegen latenzprobleme kann es aber nichts
unternehmen. Die sind einfach leitungs und dsl hardware bedingt (fastpath
etc).
Man sollte auch beachten das eine erhöhte ausnutzung des upstreams sofort
konsequenzen auf die latenzen und den downstream haben. Nutzt man
beispielsweise den upstream bei dsl voll aus, wird man schnell feststellen
das der downstream nur noch bei 32 kb/s hängen bleibt. Das bedeutet. Emule
anschalten und das netz ist tot.

Für latenzkritische anwendungen ist hier SDSL besser geeignet da dieses
system nicht asymetrisch arbeitet (QDSL basiert z.b. auf SDSL)

Wir setzen aus dem grunde hier in unserem wlan netz gleich mehrere sdsl
leitungen an wo die last entsprechend verteilt wird um gerade
latenzkritische anwendungen wie VoIP zu ermöglichen. Spiele haben wir sogar
unterprioritisert weil diese nicht viel bandbreite benötigen und auch das
läuft einwandfrei

 

[joaho]

Von Brainslayer:

QOS bedeutet Quality Of Service. Allerdings ist der Begriff hier eher auf
die Bandbreite bezogen und nicht auf die Latenzen die je nach
internetanbindung sehr interschiedlich ausfallen. Das problem ist das der
Router nicht weiß wie er angebunden ist und welche charakteristik die
leitung hat. Um Latenzarme applikationen über ADSL zu garantieren musst du
die maximale portanzahl enorm einschränken. Das trifft aber dann wiederum
nur auf ADSL zu.

 

[joaho]

Und hier mein erstes Thema:

Das problem ist das der
Router nicht weiß wie er angebunden ist und welche charakteristik die
leitung hat.

OK, das muss man ihm also mitteilen, du empfiehlst 80% der Bandbreite einzutragen. Der tatsächlichen, oder der vertraglichen?
Was passiert, wenn die tatsächliche Bandbreite höher ist, als die eingetragene? Wird die Differenz verschenkt?
Wie reagiert DD, wenn die tatsächliche Bandbreite niedriger wird, als eingetragen?

 

[BrainSlayer]

das geht am problem vorbei. es geht nicht um bandbreite den davon braucht CS z.b. nicht viel. es geht hier um latenzzeiten und die kann man nur durch portpriorisierungen lösen und auf dinge wie filesharing etc. verzichtet. in der nächsten DD-WRT version wird es definitiv erst mal eine einstellmöglichkeit für die maximale portanzahl geben. applikationsbezogene portangaben wird es aber da warscheinlich noch nicht geben. dessweiteren mußt du bei wlan beachten das jede störquelle deine pingzeiten erhöht. ich habe als beispiel eine funkstrecke über 8 km zu meinem access point gezogen wo es dann via 5 Ghz zum initialpunkt geht. ich habe dabei latenzen von 4 ms. aber wir haben auch leute im netz die latenzen von 300 ms haben weil es einfach zu viele störquellen in der gegend gibt und das beeinflusst wlan erheblich. prüf doch einfach mal wie hoch deine latenzen zu deinem hausap sind. also einfach anpingen und mal ne minute beobachten

 

[joaho]

das geht am problem vorbei.

Trotzdem hätte ich es gerne gewusst, ich will kapieren, wie das funktioniert.

(WLan ist disabled und die Antennen sind abgeschraubt, ich hab den WRT nur wegen Qos und open firmware gekauft. Ping zum WRT ist 1 ms.)

 

[BLJ]

das geht am problem vorbei.

Trotzdem hätte ich es gerne gewusst, ich will kapieren, wie das funktioniert.

(WLan ist disabled und die Antennen sind abgeschraubt, ich hab den WRT nur wegen Qos und open firmware gekauft. Ping zum WRT ist 1 ms.)

ich auch.
Bin n bisserl enttäuscht von den QOS Optionen (das ist keine Kritik an den Entwicklern, nein, ich schätze ihre Arbeit sehr! ich hätte mich lediglich besser informieren sollen).

Also ToDo sehr hoher Priorität für QOS würde ich

ACK Paket Prioritisierung

nennen.

Durch ACK Paket-Priotisierung verschwindet der Nachteil von A(symetric) beinahe.
habe eine 600/100 ADSL Leitung, mit ACK Paket Priotisierung lagt es vieeel weniger...

wenn ich den DL vollständig auslaste und nebenbei BF42C (DesertCombat) zocken will, so habe ich ohne ACK Paket Prioritisierung(aka Traffic Shapping) einen Ping von ~300.
Mit Traffic Shapping schwankt er dann zw. meistens um die 50-80 bis manchmal Ausreisser auf etwa 130-170. Die sind aber nicht so krass oft, es ist knapp spielbar.

Schon mal sehr gut... oder?

mit Ack Paket Prioritisierung (1. Priortät im QOS 'Ast') kann man auch den DL & den Upload gleichzeit voll ausnützen...

zur Information:

ACK -Paket sind die Acknowledge -> Bestätigungspackete für den Erhalt eines Paketes. Erst wenn der Seeder das ACK Paket erhält, schickt er das nächste Datenpaket. Kommt das ACK Paket nicht / zu spät, so gibt's n Timeout, und der Seeder versucht das ursprüngliche Datenpaket nochmals zu schicken.

So läuft des AFAIR mit TCP/IP.


Wenn also das ACK Paket ne lange Latenz hat, geht es dementsprechend viel länger, bis man das nächste Datenpaket erhält...
es hat ~den grössten Effekt...


Frage: Gibt es ne Möglichkeiten 'eigene' Applikationen zu definieren?

Thanks

cya

 

[bjunix]

also das problem bei linksys firmware besteht darin das es auf kernel 2.4.20 basiert (so viel ich weis).
der priorisierungs logarithmus hfsc, welcher für die latenzzeiten der packete verantwortlich ist, ist allerdings erst ab kernel 2.4.25 unterstützt.

also wenn ihr eine saubere qos lösung auf eurem linksys haben wollt, dann spielt euch openwrt drauf und konfiguriert qos mit tc per "hand". eine andere möglichkeit gibtes meines wissen nach nicht.

 

[BLJ]

ok dann werd ich mich mal anach openWRT umschauen ;-)

hab ich mir eh schon gestern mal angeschaut... gibt wohl wieder n bisserl Arbeit ;-)

thx
cya

 

[stefanmoench]

bitte auf jeden fall melden wenn es erfolge mit wrt54xx + openwrt + hfcs gibt

danke

 

[bakajikara]

also das problem bei linksys firmware besteht darin das es auf kernel 2.4.20 basiert (so viel ich weis).
der priorisierungs logarithmus hfsc, welcher für die latenzzeiten der packete verantwortlich ist, ist allerdings erst ab kernel 2.4.25 unterstützt.

also wenn ihr eine saubere qos lösung auf eurem linksys haben wollt, dann spielt euch openwrt drauf und konfiguriert qos mit tc per "hand". eine andere möglichkeit gibtes meines wissen nach nicht.

aehem.........lass mal stecken mit 'saubere loesung' bei openwrt.

die jungs klatschen dir ein r/w jffs2 auf den ganzen flash und haben damit immer mal gerne ihre probleme.
solltest du dann noch auf eine andere firmware, wie zb DD-WRT (welches auch ein jffs mitbringt) umsteigen, hast du dort mit grosser wahrscheinlichkeit ein jffs mit 100% platz benutzung (weil openwrt mist gebaut hat) und kannst es somit nicht benutzen.

mit solchen tipps waer ich mal vorsichtig bevor ich mich nicht selbst erstmal richtig schlau gemacht haette!

bakajikara

 

[bjunix]

fakt ist nur mal das dd-wrt und alle anderen auf linksys basierten firmwares hfsc nicht unterstützen.
und hfsc ist einfach das A und O für voip, weil du damit die latenzzeiten der packete beinflussen kannst; simple "bandbreiten-zusicherung" und "queuing-priorisierung" reicht für voip leider nicht.

das ist alles was ich gesagt habe. mit sauberer lösung meine ich die qos implementierung für voip die bei dd-wrt (und bei allen anderen) einfach nicht richtig funktionieren _kann_, da der kernel zu alt ist. wenn du dir die tc config mal bei linksys basierten firmwares anschaust weist du wieso es mit voip und qos nicht klappen kann. ( vorrausgesetzt man hat sich schlau gemacht )

 

[init5]

Hallo,
tschuldigung wenn ich hier einmal zwischen poste, aber bedeutet das denn, dass QOS mit Linksys Routern und einer geringeren Bandbreite nur mangelhaft bzw. überhaupt nicht richtig funktioniert?
Das Problem mit den Latenzzeiten stellt sich für mich nicht als Problem dar, da ich hier eine SDSL-Leitung (Up/Down 512kbit) habe.
Trotzdem ist QOS in den aktuellen Firmware (ich habe schon so viele durchprobiert) irgendwie nicht richtig zu gebrauchen.

Gruß
Init5

 

[bakajikara]

@bjunix

das ganze gefasle wegen qos und co ist bei deinem statement zweitrangig.
in erster linie steht das problem und die tatsache im raum dass sich gerne mal mit openwrt und deren dort verwendetem jffs2 ganz gewaltige probleme auftun koennen.
aber ich seh schon, so richtig lesen kannst oder willst du anscheinend nicht.
ganz im gegenteil ist es eher ein witz dass du hier user auf openwrt scharf machst ohne auch auf die o.g. probleme mit dem mitgebrachten filesystem aufmerksam zu machen.
BrainSlayer hat nicht um sonst probleme mit jffs2 und ich hab mir auch nicht umsonst das gedoens um die ohren gehauen.

bakajikara

 

[bjunix]

also ich versteh echt nicht wo dein problem ist. zuerst einmal würde ich dir empfehlen einen objektive diskussions stil dir zu eigen zu machen.

die aussage bzw frage ob ich nicht lesen könnte hat nichts sachliches an sich und ist hier in einem forum, das eigentlich eine recht respekt volle umgangsform mit sich bringt, einfach fehl am platz.

und zweitens versteh ich auch nicht was dein problem mit openwrt ist. das jffs2 natürlich seine probleme mitbringt steht ja nicht zur diskussion.
ich selber habe openwrt am laufen und hatte bisher noch keine probleme mit jffs2( auch nicht bei einem downgrade auf orginal firmware)

aber entgegen deiner aussage ist dies eben nicht gegenstand der diskussion sonder QOS ( wie der thread titel schon aussagt). Wenn du dich über die Verlässlichkeit von jffs2 unterhalten willst mach ein 2ten thread auf oder geh ins openwrt forum.

desweiteren verleite ich auch keinen einfach so openwrt zu flashen. dies setzt eh einen etwas umfangreicheres verständniss von OS und hardware vorraus und ich gehe mal davon aus das leute die sich openwrt flashen auch ein gewisses verständniss von den gefahren und "nebenwirkungen", die von einem grosseren eingriff in die firmware ausgehen, mit sich bringen.

Allein die tatsache das openwrt kein "hausgemachtes" webinterface mit sich bringt, lässt es dem otto-normal-router-user( oder soll ich lieber computer-bild-leser sagen, aber dann würde ich auf deine umgangsformen zurückfallen ; ) eh schon an der konfiguration von open wrt scheitern. nichtsdestotrotz gehe ich davon aus das user die ihr QOS über tc selber konfigurieren wollen das nötige know how haben mit jffs2 zurechtzukommen bzw mit den negative seiten von jffs2 leben zu können.

 

[pygmalion]

Finde ich auch nicht dolle, einfach mal ein paar Sachen in den Raum zu werfen, ohne weitere Begründung. Bin kein Linux-Freak, aber würde trotzdem gerne wissen, was den nun das Problem an jffs2 ist? Ich bitte um Erleuchtung... (wenn möglich bitte in einem sachlichen Ton...)