Mit welchen Providern klappt Traffic Shaping?

[Gag_Halfrunt]

Es ist nicht die Bandbreite, die da reinhaut, sondern die Anzahl der Requests. Da liegt wohl der Hund begraben.

 

[addy75]

Beim funzt es nicht !!! Sobald ich eMule etc. beende geht das => Die Box kann das Shaping nicht richtig

 

[TWELVE]

Hatte die letzten Firmwares auch immer stark unter dem nicht-funktionierenden Shaper gelitten, doch seit Version 06.03.37 scheint
dieser endlich zu funktionieren.Wer noch nicht auf der Version ist und es versuchen will, dem würde ich auch einen Reset auf Werk empfehlen.
Danach auch einmal Strom ab/dran, das hat die letzten Probleme beseitigt.

Grüße

TWELVE

 

[cyberpeter]

@ addy 75

Also nochmal, das Problem bei Emule ist nicht, das nicht mehr genug Bandbreite für VOIP zur Verfügung steht, sondern das die Box mit der Anzahl der Verbindungen ein Problem hat. Die Box ist ausgelastet und hast nicht mehr genug Rechkapazität um auch noch VOIP zu händeln. Dies ist aber nicht nicht nur der FritzBox anzulasten. Emule schließt leider offene Verbindungen nicht zurverlässig. Das heißt es gibt weitaus mehr Verbindungen als Du als Limit eingestellt hast. Es gibt sogar viele Router, die damit überhaupt gar nicht klar kommen und einfach abstürzen, was bei der FritzBox seltener der Fall ist.
Meines Wissen gibt es im Moment keinen ATA mit Routerfunktion, der mit EMule wirklich 100 % ig klar kommt.

@ Gag_Halfrunt

Hatte Dir ja angeboten, dass Du mal die Werte aus deiner DSL-Info der FritzBox postest. Dann können wir unsere Werte ja mal vergleichen. Vielleicht kommen wir ja dann dem Problem auf die Spur.

 

[cyberpeter]

edit

 

[Gag_Halfrunt]

@cyberpeter: So, ich sitze jetzt vor meiner Box.

Signal/Rauschtoleranz: 23 - 25 dB
Leitungsdämpfung: 37 dB

Diese Werte hab ich mit einem nagelneuen Splitter. Mit meinem alten lag die Signal/Rauschtoleranz bei 21 bis 23 dB. Hat sich aber sonst nichts weiter an der Telefon-Qualität verändert.

 

[JSchling]

Also Emule lief bei mir das ganze Wochenende. Mal davon abgesehen, dass die Box am Samstag morgen um 6:20 rebootet hat (warum auch immer, so halt im Logfile zu erkennen) hatte ich 0 Probleme, also auch Telefonieren war einwandfrei.
Und surfen etc geht auch voellig problemlos bei mir. Gerade nochmal getestet mich selber anzurufen und vom ersten Moment an klaren Sound. Wahrenddessen lief ein FTP-Upload zum 1&1 Server mit ca 22kb/s welcher auch sofort wegbrach auf 13-14kb/s. Auch andersrum, beim Download erreiche ich korrekte 239-240kb/s, doch geht bei Anruf schlagartig runter auf 220-222kb/s, der Windows Commander zeigt die aktuelle Transferrate dabei auch sehr schoen an. Das ganze mit der Fritz-WLan-Box und eigentlich mit allen Firmware-Versionen die es gab (seit der ersten 09er), angeschlossen via 1&1-DSL-2000. Nix besonderesm habe auch teilweise nur 14db Rauschtoleranz (aber meist so 18-21) und stabile 37db Daempfung.
Also ich weiss nicht warum es bei mir (und 2 Bekannten die auch wegen mir so ein Teil haben) so toll geht (wohnen alle in der gleichen Stadt, gleiche Telekomvermittlungsstelle), aber es hat eigentlich nie Probleme gegeben, die anderen beiden haben sogar nur DSL-1000.
So direkt raten kann ich auch nur nach jedem Update ein Werksreset zu machen, unabhaengig vom Traffic Shapening hatte ich da selber schonmal Probleme.
Von Traffic Shapening bin ich auch schwer begeistert, wo ich waehrend so einem Telefonat bei vollem FTP-Upload auch weiterhin fast problemlos surfen kann. Also keine Frage, es ist etwas traeger, aber so grundsaetzlich gesehen klappt das trotzdem super fit. Auch das VAD kann man dabei gut bemerken, wenn man nicht redet geht der Upload gleich wieder heftig nach oben und das auch recht schnell, laesst aber noch viel schneller wieder nach, wenn VoIPmaessig aktivitaet da ist. Ab und an gibts mal kleine Knackser im Telefon, aber das so alle 3-5 Minuten mal, also in meinen Augen voellig akzeptabel.
Vielleicht nicht so direkt Standart, aber diese UPnP-Optionen hab ich aus, auch keine Infos, UPnP hab ich auch am PC komplett deaktiviert. Und eingestellter Codec fuer VoIP ist aktuell G726-24, bis vor kurzem noch G726-32 verwendet, auch problemlos. WLan nutze ich garnicht, bei mir haengen 3 PCs und eine dbox via Kabel an der Fritz, aber eine der beiden Boxen die ich so betreue nutzt nur WLan und Traffic Shapening klappt genauso. Im Windows hab ich QoS voellig deaktiviert, wuesste auch erstmal keine Anwendung, die das unterstuetzen wuerde.
Also was auch immer hier gesagt wird, aber das Traffic Shapening in der Box nicht funzt ist absolut nicht richtig, bei mir klappt das sowas von 100%ig gut. Dabei ist mir klar, dass ich da nur wenig Einfluss drauf habe, dementsprechned auch nicht wirklich denke es sind Userfehler, bei denen wo es offensichtlich ganz und garnicht laeuft und zu geben scheint es die ja schon. Netzwerkmaessig hab ich die MTU-Size bei allen PCs auf fuer Telekom korrrekte 1492 eingestellt, falls sowas der Box zu schaffen macht, aber sonst ist WinXP mit und ohne SP2, W2k und 98 dabei und alle tun es korrekt.
Vielleicht wirklich eine Frage der Vermittlungsstelle.

 

[addy75]

@ JSChling

Wie sind denn deine eMule Einstellungen ?

Die Rauschtoleranz ist 22db
Leitungsdämpfung 14db

Der Upload bricht bei mir auch ein ABER der Gegenüber versteht NIX.
Die Frage ist nun, was hat die MTU mit der Box zu tun? Du änderst die MTU für die IP Pakete, die Box ändert die MTU für die PPP-Paktet selbst ein. Schön und ? Der Sinn bleibt mir genauso verborgen wie die Installation von Cfoss. Der Box sollte es doch egal sein, wie groß die MTU ist....
Wenn sie schon Rauschtoleranz etc. erkennt dann sollte MTU für sie'n Klacks sein !!!

 

[addy75]

@ JSChling

Wie sind denn deine eMule Einstellungen ?

Die Rauschtoleranz ist 22db
Leitungsdämpfung 14db

Der Upload bricht bei mir auch ein ABER der Gegenüber versteht NIX.
Die Frage ist nun, was hat die MTU mit der Box zu tun? Du änderst die MTU für die IP Pakete, die Box ändert die MTU für die PPP-Paktet selbst ein. Schön und ? Der Sinn bleibt mir genauso verborgen wie die Installation von Cfoss. Der Box sollte es doch egal sein, wie groß die MTU ist....
Wenn sie schon Rauschtoleranz etc. erkennt dann sollte MTU für sie'n Klacks sein !!!

 

[brontalo]

Hab mir den Thread nun durchgelesen, und alle tappen hier anscheindend im dunkeln. Und ehrlich gesagt soll uns das egal sein woran das alles liegt, es funktioniert eben nicht wie es sollte.
Aus der Kundensicht sollte ja so funktionieren, dass egal wie heftig man im Netz surft oder P2P betreibt, wenn ich VOIP telefoniere sollte die entsprechende Bandbreite VOIP zustehen. Punkt. Wie man das nun nennen darf, ob TrafficShaping oder QoS ist für den Kunden völlig egal!
Mag sein dass hier einige 'Experten' (wozu ich mich gern dazuzähle) Vermutungen anstellen, aber die Experten, die sich wirklich Experten nennen sollten sind AVM Entwickler, die wohl die Versprechen des Marketing ausbaden müssen.

Bei mir habe ich folgendes beobachtet:

Alles bei voll ausgelasteter Internetleitung (gleichzeitig 'stark' laufenden edonkey + Azureus + FTP)
"Bandbreitenoptimierte Sprachkompression verwenden" ist bei mir ausgestellt, denn damit funktioniert alles etwas besser, auch wenn die Theorie dem wiederspricht
Ich benutze das kleine Programmchen Netlimiter, wo ich die Upload Bandbreite bei jedem Telefonat runterdrehe (hab 3096/384 Leitung), bei Sipsnip muss ich bis auf ca. 5kB/s runterdrehen, damit es für den Telefonpartner ok klingt bei GMX recht es sogar wenn ich nur auf 30kB/s runterdrehe. Ob "Bandbreitenoptimierte Sprachkompression verwenden" an oder aus ist gibt es (mehr oder weniger, aber nicht zufriedenstellend) Probleme mit zerhackter Sprache und Knacken in der Leitung.

Ohne ausgelastetes Internet gibt es gar keine Probleme.

brontalo

 

[JSchling]

also ich bin alles andere als ein Emule-Crack, nutz das halt manchmal wenn ich was brauche. Daher duerfte es ganz normal eingestellt sein, maximale Verbindungen steht was von 800 und Limit irgendwie 400. Uploadspeed steht auf 15, Netlimiter macht dann 4 daraus.
Ob das mit dem MTU was bringt weiss ich nicht, habs ja nur mal so erwaehnt. Tatsache die Box erkennt automatisch, dass 1492 korrekt ist und wandelt die lokalen Packete entsprechend um. Keine Ahnung was das an Arbeit fuer die Box bedeutet, aber wo man es der Box easy ersparen kann und die Packete auch korrekt fertig zum Weiterversenden an die Box geben kann, sehe ich darin alles andere als einen Nachteil, dies auch so zu tun.
Selbst wenn ich hier keinen direkten TrafficShapening Einfluss sehe, aber als DNS-Server hab ich im Windows auch die von meinem Provider eingetragen, stehen ja auf der Box im Systemlog nach jeder Einwahl. Wo Packete auf Port 53 per se priorisiert sind, sehe ich auch hier keinerlei Nachteil, der Box die Umsetzung zu ersparen und schicke Anfragen vom PC direkt an den DNS-Server. Einziger Nachteil, dass man nur ueber die IP auf die Box kommt und das ist mir wiederrum egal.

 

[TWELVE]

Der Box sollte es doch egal sein, wie groß die MTU ist....

Naja, das ist so nicht ganz richtig, da die Max MTU bei PPPoE-DSL 1492
ist ( 1500-8 Bytes für PPPoE Header).Bei einigen Providern ist sie sogar noch kleiner ( AOL 1400).Bei Überschreiten dieser Max. MTU müssen Pakete fragmentiert werden.Dies wirkt sich erstens ganz schlecht auf die Peformance aus, und zweitens unterstützt nicht jeder Router oder Server
im Internet Paketfragmentierung, was der Grund dafür ist, das man auf dem PC besser die PMTU Discovery aktiviert hat, um genau diese Effekte zu vermeiden.


Grüße

TWELVE

 

[addy75]

@ JSchling

Ich habe bei mir als max. Verbindungen 250 stehen. Also müsste meine Box ja WENIGER Verbindungen zu handeln haben. Also kann so daran so nicht liegen oder ?

@ Twelve

Was bringt es auf dem PC die PMTU, und wo da, zu ändern? Für den PC ist das ein Netzwerk und die Box wandelt die Pakete für's I-Net um. Da ist dem PC doch egal, was hinter seinem Netzwerk kommt, denke ich mal.

Nichts destotrotz hat die Box massive Probleme die VoIP - Pakete zu priorisieren etc., wenn eMule läuft. Da JSChling MEHR Verbindungen hat und sich die Qualität nicht mit den Verbindungen ändert, muss es auch noch irgendwo anders dran liegen. Oder die Box ist schon mit sehr wenigen Verbindungen überlastet.

 

[traxanos]

ich weis nicht warum ihr so probleme hab.
es liegt jedenfalls nicht am Trafficshapping.
Da ihr natürlich alle das Wort leider falsch
benutzt wird AVM versuchen unter diesem
Begriff ein vernünftiges QoS zum laufen zu
bekommen, aber oft ist es garnicht das DSL
sondern der Provider oder genauer die Region
wo Ihr DSL bekommen hab.

Ich habe festgestellt das die meisten mit Problemen
in Orten wohnen wo der DSl-Backbone start belasstet ist.

Ob das evtl bei euch auch ist weis ich nicht, jedenfalls:
Trafficshapping sorgt nur das der Upload der Daten
1. nicht überlasstet ist (hauptl. Interessant bei TCP Verbindungen)
2. das die PPPoE Frames nicht im Modem gepufferd werden.
3. Download wird auch kleiner gehalten das bei vollem Download
auch der Upload nicht einbricht.

 

[addy75]

@ Traxos

Soso. Wieso funzt es dann ohne Probleme, wenn eMule aus ist? Fakt ist, dass bei hohem Upload (und eMule) ein Telefonieren nicht möglich ist, da die Gegenseite alles nur zerhackt versteht. Ich verstehe sie jedoch ohne Probleme.
Ob QoS oder TS, Fakt ist, dass es nicht richtig geht. Wenn man es nicht benötigt geht alles 1a. M.E. liegt es daran !

 

[Gag_Halfrunt]

Mir ist es eigentlich auch egal, wie die Funktion heißt. Die Box wurde mit der Eigenschaft verkauft, dass man gleichzeitig telefonieren und im Internet surfen kann. Von qualitativen Einschränkungen ist keine Rede.

Und dass bei Sipgate schon geringe Zugriffe ohne Filesharing ausreichen, um die Verbindung ins Stocken zu bringen, liegt doch wohl definitiv an der Box, oder ja?
Dass insbesondere bei Sipgate dermaßen viele Probleme auftreten, liest man hier im Forum in diversen anderen Threads.

Dass daran jetzt plötzlich der DSL-Backbone dran schuld sein soll, passt doch auch nicht. Wenn der Backbone "überlastet" wäre, dann würden die paar Zugriffe mehr auf meiner Box da doch den Kohl nicht fett machen. Dann wären doch auch im Standalone-Betrieb kein Telefonat möglich.

Gag

 

[addy75]

THX @ Gag_Halfurt

Meine Rede.
Die Sache ist ja auch die, dass es bei SipSnip und dei dem "unverwüstlichen" GMX auch auftritt

 

[traxanos]

Ich habe nur gesagt das Trafficeshapping selbst nicht wirklich was damit zu tun habt und Ihr nur dafür sorgt das wieder Begriffe falsche interpretiert werden, da man sich wieder nicht die mühe macht und erstmal herausfindet was eigenbtlich dieser Begriff bedeutet.

Außerdem scheint das Problem ja nicht bei allen zu sein.
Was wiederum darauf schließen läßt das die Problematik nicht
immer die BOX sein muss auch wenn man es gerne auf diese
schieben möchte.

Desweiteren ist mir lediglich aufgefallen das die meisten Probleme
in kleineren Regionen nicht so stark auftretten als jetzt in größeren.

Das einzige was ich eingentlich Bewirken wollte ist wieder mal falsche
Informationen an den dummen User weiterzugeben der nacher anfängt
und irgend einen Müll zu erzählen. Das Forum ist ein Fachforum für VoIP
und ich denke wenn jemand euch schön erklärt das der Titel dieses Threads in sich ein widerspruch ist solltet Ihr nicht so abweisend sein.

Fakt ist: Der Provider hat nichtss mit TrafficShapping am Hut und gut ist!

 

[Gag_Halfrunt]

Dann magst Du mir sicher die Zusammenhänge in Sachen Störanfälligkeit zwischen unterschiedlichen VoIP-Providern und unterschiedlich starkem parallelen Internet-Traffic erklären. :roll:

Natürlich hat der VoIP-Provider mit der Funktion des TS als solches nichts zu tun. Aber die Verbindungen zu ihm wird durch das Verhalten der Box beeinflusst.

Gag

 

[JSchling]

@traxanos:
Also Traffic Shapening als Begriff wird z.B. auch von cFos genutzt (http://www.cfos.de/techinfo/shape.htm - mit Erklaerung) und anders macht es die Fritzbox ja auch nicht.
In der ar7.cfg kann man das ja schoen sehen: Priorisiert werden insbesondere filter = "tcp and len <= 64"; (=ack-Packete) und auch filter = "udp[8] = 0x80 or udp port 5060"; (=VoIP-Packete) . Eine geringere Prioritaet haben dann als 2tes DNS-Anfragen filter = "udp port 53"; sowie filter = "(tcp dst port 80 or dst port 8080 und filter = "icmp";. Mit der geringsten Prio 0 werden dann alle anderen Packete behandelt (name = "default"; filter = ""; priority = 0
Das kann man als Traffic Shapening bezeichnen und wie oben beschrieben klappt es bei mir bestens !! Heftig Up- und/oder Download via FTP bricht weg sobald ich telefoniere, aber auch da nur soviel wie benoetigt wird. Ich hab VAD aktiv und wenn wenig geredet wird = wenig VoIP Daten durchgehen, steigt die Uploadrate/Downloadrate auch gleich wieder an, auch wenn ich weiter telefoniere und laesst eben nach, wenn mehr VoIP Daten anfallen und das klappt einwandfrei bei mir, ab und an knackst es mal in der Leitung. Wenn ich wie hier schon beschrieben noch gleichzeitig anfange zu Surfen, bricht der FTP Up-/Download ohne Beeintraechtigung des Telefonates weiter ein und Surfen klappt ganz gut. Also greift auch die Regel, dass DNS-Anfragen und HTTP-Requests (destination (dst) Port 80 und 8080) bevorzugt bearbeitet werden. Das ist ein nettes Bandbreitenmanagement und fuer meine Zwecke voellig richtig, genauso so brauche ich das zu hause und so wird es wohl bei den meistens sein, zumindest im privaten Berreich.
QoS sehe ich hier nirgends, denn es werden Packete bevorzugt nach der Art der Packete (tcp-ack filter = "tcp and len <= 64" und dem Port (filter = "udp port 53" aber unabhaengig vom Programm, welches diese Ports benutzt. Es ist also egal, ob z.B. die DNS-Anfrage von der Fritzbox selber gemacht wird (sprich im Windows die Fritzbox als DNS Server angegebe ist), oder ob ich direkt vom PC ueber Port 53 (was sonst) eine DNS-Anfrage an den DNS-Server meines Providers stelle, beides hat Prio 1)
QoS, welches dann auch im Betriebssystem aktiviert sein muss, sichert aber nur einem Programm eine gewisse Bandbreite zu, reserviert XY % exklusiv fuer ein Programm (wobei ich selber kein einziges Programm habe welches QoS unterstuetzt, neben dem Betriebssytem muss das Programm selber natuerlich auch QoS-tauglich sein, sonst kann man diesem Programm schlecht was reservieren wenn keine entsprechende Konfigurationsmoeglichkeit und ich denke das ist bei den meisten so) Dementsprechend ist QoS (wovon man bei AVM auch absolut kein Wort lesen kann) also auch ein Bandbreitenmanagement, aber da hoeren die Gemeinsamkeiten auch schon auf.