WRT54G-Firmware mit der besten QoS-Funktion?

WRT54G-Firmware mit der besten QoS-Funktion? (4 Beiträge, 188 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Diesmal habe ich ein ziemlich spezielles (aber IMO sehr interessantes) Anliegen.

Ich bin mit der QoS-Funktion von der DD-WRT v.23 nicht wirklich zufrieden, um genau zu sein nicht zufriedener als mit der Original-Firmware.

Wieso ich QoS brauche? Weil ich über SIP mit Adapter VoIP-telefoniere.

Ich habe schon auf die verschiedensten Arten versucht, das QoS zu konfigurieren:

1.) Beschränkung der Upload- und Downloadrate auf ca. 80% der vom ISP zur Verfügung gestellten Bandbreite.
2.) Priorisierung nach MAC- bzw. IP-Adressen (ist möglich, da der Adapter natürlich eine andere MAC- und IP-Adresse hat als die PCs)
3.) Priorisierung nach physikalischen Ports (Ethernet-Anschlüssen)
4.) Priorisierung nach Ports bzw. Services (letzteres nur beim DD-WRT, mittels packet filterings durch L7-Filter)

Ich habe die Methoden 2.)-4.) einzeln bzw. in den verschiedensten Kombinationen ausprobiert, Methode 1.) war immer aktiv da sich damit immer zumindest eine leichte Verbesserung ergab.

Das Problem: Bei offener VPN-Verbindung und Filetransfer darüber (ab einer dadurch verursachten Belastung des Breitbandanschlusses in einem Ausmaß von ca. 60%) ergeben sich bei VoIP-Gesprächen Verzögerungen (hin-retour) von bis zu einer ganzen Sekunde, und auch andere Störungen (Knackser etc.).

Der L7-Filter von der DD-WRT Firmware schaut auf den ersten Blick eigentlich sehr gut aus, und hat auch bereits viele Services vorkonfiguriert (z.B. ciscovpn, SIP,...), funktioniert bei mir in der Praxis allerdings auch nicht wirklich besser als die anderen Methoden.

Gibt es vielleicht eine QoS-Funktion, die man noch im Nachinein zur DD-WRT dazuinstallieren kann? Oder gibt es eine Firmware, die bzgl. QoS besonders gut ist?

Ich bin gespannt, ob sich hier jemand mit diesem Problem schon eingehend beschäftigt hat, oder mir doch nur in einem anderen Forum geholfen werden kann.

MfG Beel

mein voll die krasse System: Intel 8008 CPU (8 Bit, modifizierte in FPGA realistierte Version), 1K ROM, 96 Bytes RAM triple channel, 12 Layer PCB, 7Segment Grafik, HDD: wozu? habe ja 8 Stk. 5.25" Floppy (mit verringerter Spurbreite für höhere Datendichte) in Raid0, Kühlung: Kompressor-Wasser Kombination, Gehäuse: Siemens GT 30 K 920 Gefriertruhe mit Kabeleinlass

Nichts? *nachobenschieb*

MfG Beel

hallo!

da ich dir die hardware empfohlen habe muss ja quasi von mir auch eine antwort kommen. das gleiche problem hatte ich auch und konnte mit originalfirmware nicht lösen (damals 3.0irgendwas) das dortige qos brachte linderung aber keine abhilfe.

erfolg nach VIEL herumprobieren lieferte mir sveasoft's alchemy fast astreine resultate.

siehe http://forum.geizhals.at/t325665,2468066.html#2468066

seit dd-wrt v23 final ist habe ich diese mit den gleichen settings installiert und kann bis dato keine unterschiede feststellen. so richtig auf die probe gestellt habe ich das qos allerdings nicht.

da aber der quellcode vom qos fast zur gänze aus sveasoft quellcode stammt (stammt, und nicht entspricht!), erlaube ich mir annahme das qos unter dd-wrt müsste NICHT SCHLECHTER funktioniert als bei sveasoft alchemy.

wie ich sagte, bin ich nach viel herumprobieren bei gewissen settings fündig geworden. und zwar:

bandwith:

nimm immer 90% bei upload! in deinem fall 345. schon etwas mehr und die ack priorisierung ist pfutsch. viel weniger ist auch nicht gut. warum? keine ahnung!
download: da kannst du einen wert zwischen 90 und 95% einstellen: ich habe zb 2850.

auch wenn chello langsamer laut speedtest laufen sollte ist das nicht so ein problem. er kann ziemlich gut damit umgehen. das kritische am qos ist der upload. wenn der läuft, dann hast du schon mehr als die halbe miete.

ethernet port:

leerlassen. bringt nichts da die limitierung sowohl download und upload beeinflusst, funktioniert nicht so genau (manchmal mehr, manchmal weniger) und die mindestlimitierung bei über der hälfte des upload liegt. ich hatte ausserdem schon den sipura als chello noch 128 up hatte. da war die sache noch kritischer.

mac priority:

so regelte ich früher den verkehr. funktionierte gut aber nicht so wie ich wollte. das problem mit mac priority ist dass der qos NUR mac priority kennt wenn es eingestellt ist und alle andere parameter verwirft. (ethernet port/netmask/application). also hände weg.

netmask priority:

da sind die einzelclients einzutragen. fang an mit dem sipura adapter und gib ihm unbedingt premium priority. bei mir schaut's also so aus:

10.0.0.10 32

trage einfach NUR die adresse des sipura adapter und schau ob jetzt der qos greift. standardgemäss haben alle unspezifizierte clients standard priority. wenn's bei dir funktioniert und das verhalten ok ist dann lasse es so. ansonsten kannst du weitertweaken um ein wenig mehr herauszuholen.

als allererste: netmasks einzutragen hat bei mir NIE funktioniert, also trug ich immer einzelIPs mit netmask 32. auch hier: warum? keine ahnung.

meine zwei clients (pc + notebook) beispielsweise bekommen 'express' priority. mein htpc und downloadmaschine trage ich gar nicht ein sodass hier standardpriority entsteht. andere besucher die ips aus dem freien dhcp bereich bekommen ebenfalls automatisch standardpriority.

services priority:

diese priorisierung steht einem rang unter der der netmask priority. also, wenn dort etwas eingetragen ist, dann gilt das was dort steht ausser hier stehen services auf einer NIEDRIEGEREN priority.

beispiel: mein pc bekommt über netmask priority explizit 'express'. stelle ich emule auf 'bulk' wird emule auf 'bulk' gefahren. sollte ich emule auf 'premium' stellen ignoriert der qos diese einstellung FÜR MEIN PC weil ich den ganzen pc bereits auf 'express' gestellt habe.

eine priorisierung nach oben kann nur für pcs erfolgen die NICHT in der netmask priority eingetragen sind (und das unabhängig davon ob hier von haus aus eine 'standard' priorisierung greift)

ich beispielsweise habe ich nur beide services bittorrent und emule als 'bulk' eingetragen. weil nur die 2 die internetverbindung extremst belasten. es wäre hier bei dir ratsam entweder den ganzen computer als standard zu fahren oder falls du unter netmask priority den computer auf 'express' hast den vpn client doch etwas auszubremsen und ihm 'standard' priority geben. notfalls sogar 'bulk' wenn er das gut verträgt.

----------

zu deinem speziellen fall:

ich mache mir nur sorgen in deinem fall über die übermenge udp die der vpn client erzeugt (du schreibst ja du erzeugst sehr viel traffic damit). bei jeder probierrunde stelle den vpn client auf TCP um. bei udp kann der qos praktisch nichts anders machen als pakete verwerfen. in der regel mag kein qos der welt über 20% der udp pakete verwerfen weil er weiss dass udp oft zum real time tasks eingesetzt wird und die reconstruct mechanismen extrem beschränkt sind. der sipura beispielsweise kann nur 160ms rekonstruieren. alles was drüber ist fehlt oder erzeugt einen knackser (auch hier, stelle den sipura jitter auf 'extremely high', es kann helfen)

in dem fall aber nicht. in dem fall fahrst du link control auf einer höheren protokollebene (bei ipsec selber), der router kriegt das aber wahrscheinlich nicht mit. drum, sollte es nicht funktioniere stelle auf tcp um, darauf hat der router mehr einfluss und kann mit ack und transfer windows das ganze besser in den griff kriegen. vor allem weiss er dass wenn ein paket verworfen wird, dass der tcp automaten an beiden enden das paket wieder anfordert. das weiss er nicht ad hoc vom udp.

Wow, das wird alles sofort in die Tat umgesetzt und getestet. Auf dich ist Verlass.

MfG Beel

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung