Unitymedia Firmwareupdate UM 6360 Cable 85.05.09

[sebr]

Eigentlich ist mit der 85.05.09 der Energieverbrauch gesunken. Irgendjemand hier im Forum hatte sogar mal nachgemessen. Außerdem zeigt auch der Energieverbrauch geringere Werte al mit alter Firmware an, wobei das aber auch nur andere Skalierung sein kann. Und man merkt es deutlich am WLAN: Reichweite ist wesentlich geringer geworden!
Aber ein Test mit anderem Netzteil kann nicht schaden. Auf die Maße und Polarität des Hohlsteckers achten - neben Spannung und Strom natürlich! Außerdem sollte das Netzteil stabilisiert sein.

 

[CapFloor]

@whale:
Benutzt Du zum Upload "rsync", z.B. für Strato? Dann lade mal testhalber eine größere Datei per ftp/http hoch und überprüfe, ob in diesem Fall die Probleme immer noch existieren.
Viele Grüße
CapFloor

 

[whale]

Ja, das Netzwerksicherungs-Modul meines NAS benutzt rsync (verschlüsselt über SSH) zum Backup auf das Strato HiDrive. Ich habe gerade den direkten Vergleich zum http-Upload gemacht. Beim Backup über rsync bricht der Downstream wie gehabt zusammen, beim direkten Upload über http bleibt er nutzbar. Das gleiche Phänomen wie bei rsync habe ich jedoch auch beim Upload von Musikdateien mit iTunes Match, natürlich weiß ich nicht, ob Apple hier im Hintergrund das rsync-Protokoll nutzt.

 

[josen]

Moin,


vielleicht mag mir mal jemand den Unterschied zwischen rsync und http aus Sicht des Provides erklären? Soweit ich beide Protokolle verstehe, benutzen beide TCP, sehen also für Unitymedia gleich aus, solange da niemand verschlüsselte Protokolle anders behandelt. Soweit ich weiss, können beide SACK und sind nicht dafür bekannt Probleme zu verursachen.

Grüße

 

[CapFloor]

Na, dann handelt es sich um das Problem, mit dem ich mich (und AVM) schon beschäftigt habe. Neben der Benutzung von http/ftp für den Upload (was aus verschiedenen Gründen schlechter als rsync ist), gibt es bisher zwei Workarounds:
1. Während des RSYNC Uploads ein eingehendes Telefonat ANNEHMEN. Dann funktioniert wieder alles normal für den aktuellen Upload.
2. Den RSYNC Trafific ein bisschen shapen. Falls dein NAS es zuläßt (über die Oberfläche oder einen shell Zugang), dem rsync Client die Option "-bwlimit=630" mitgeben. Das begrenzt die mit rsync genutzte Bandbreite auf knapp unter die für die FB "tötliche" Grenze. Der Durchsatz liegt damit nur ca. 100 kBit/s unter dem Maximum des Upstreams, also keine erhebliche Einschränkung für deinen Upload.
Das Problem tritt übrigens nicht auf, wenn mehrere gleichzeitige Uploads IN SUMME das Upstream Maximum ausnutzen, z.B. 5 http Upload gleichzeitig.

Ich hatte mit AVM begonnen, dass Problem zu analysieren. Da ich mit der FB aber noch andere Probleme hatte, habe ich es vorgezogen, die FB gegen ein Kabel-Modem einzutauschen und das Problem gar nicht mehr zu haben anstatt es weiter zu untersuchen.

Nach meiner Bewertung shapped AVM für bestimmte Protokolle den gesamten Upstream Traffic und gibt dem User nicht die gesamte zur Verfügung stehende Bandbreite (s.o. minimale Beschränkung von vielleicht 100kBit/s). Wieso das bei der FB "notwendig" ist, weiss ich nicht. Deshalb funktionieren alle (geshappten) "Standardprotokolle". AVM berücksichtigt das RSYNC Protokoll dabei schlicht und einfach nicht (oder, besser, das Shapen sollte einfach nicht notwendig sein). Da ich selbst einen 128MBit/s Zugang habe, weiss ich nicht, ob dieses Problem auch bei 64MBit/s Zugängen auftritt. Auch hier schaltet UM ja die "vollen" 5MBit/s Upstream frei.

Ich habe mich mit dem Problem und der Analyse intensiv beschäftigt. AVM wollte bei meinem Ausstieg einen Paketmittschnitt des DOCSIS Protokolls in diesem Betriebszustand der FB. Den konnte ich nicht mehr liefern, da ich zu diesem Zeitpunkt keine FB mehr hatte.

Falls Du mit AVM weitermachen willst, schicke ich Dir per PN die Ticket-Nummer (ist aus Dezember 2011). Mit UM hat das Problem, denke ich, nichts zu tun. Wie Du auch schon festgestellt hast, exisitert es erst seit dem FW Update der FB im Dezember.

Es wäre schon schön, wenn sich jemand die Mühe machen würde, mit AVM dieses Problem weiter zu untersuchen. Nur dann besteht Hoffnung auf Abhilfe in einer der nächsten FWs.

Viele Grüße
Frank

 

[josen]

Hallo,

verstehe ich das richtig, AVM führt auf der Fritz!Box 6360 ohne ausdrücklichen Wunsch des Benutzers Traffic-Shaping durch und reduziert dadurch die maximal zur Verfügung stehende Bandbreite?
Ist das Hörensagen oder gibt es dafür einen Beleg? Wäre interessant zu wissen

Grüße

 

[whale]

@CapFloor:
Bin absolut interessiert daran, mit AVM weiter auf eine Problemlösung hinzuarbeiten. Wäre für die Ticket-Nummer als PM dankbar.

Danke und Gruß,
Markus

 

[CapFloor]

josen:
Ist das Hörensagen oder gibt es dafür einen Beleg?

Das ist meine persönliche Interpretation nach Lage der Dinge: Einzelne http/ftp Uploads lasten den Upstream nie so stark aus wie Uploads mit rsync - nach eigener Messung und auch nach (ungenauer) Anzeige der FB selbst. Umgekehrt tritt das Problem nicht auf, wenn man die genutzte Bandbreite für einen rsync Upload minimal unter das (theoretische) Maximum im Upstream drückt - also etwa auf http / ftp Niveau. Ob AVM das bewußt tut oder es sich vielmehr um einen Fehler handelt, kann ich nicht sagen. Für einen Fehler spricht, dass sich der Spuk bei der Benutzung von rsync durch die Annahme eines eingehenden Telefonats beenden läßt.

@whale:
Ich werde mal was aus dem Mail-Verkehr mit AVM zusammenstellen. Dass AVM in dieser Sache von mir einen Mittschnitt der DOCSIS Pakete habe wollte, halte ich übrigens für "historisch" bedingt: Vor diesem Problem hatte ich noch ein weiteres Ticket mit UM / AVM, bei dem es sich vordergründig um ein fehlerhaftes Verhalten der CMTS ODER der FB bzgl. eben dieses DOCSIS Protokolls handelte. UM hat letztendlich einen Workaround implementiert (ich habe zu diesem Zeitpunkt eine "einzigartige" Portkonfiguration im Upstream bekommen), so dass sich AVM für "unschuldig" hielt. Da ich nach Implementierung des Workarounds wieder voll an UM gezahlt habe, stellten sowohl UM als auch AVM die weitere Analyse dieses Problems ein. Ich glaube aber inzwischen, dass auch in diesem Fall die FB die eigentliche Ursache war. Aber das ist ein anderes Thema...

Grüße
Frank

 

[sebr]

@whale:
Benutzt Du zum Upload "rsync", z.B. für Strato? Dann lade mal testhalber eine größere Datei per ftp/http hoch und überprüfe, ob in diesem Fall die Probleme immer noch existieren.
Viele Grüße
CapFloor

Was heißt denn "größere Datei"? Ich lade gerade einige iso Images per rsync hoch zum Test. Es sind schon mehr wie 1GB problemlos über die Leitung gegangen...

 

[whale]

@sebr
Dann kannst Du Dich glücklich schätzen. Bei rsync ist bei mir die Problematik aber unabhängig, wie groß die Dateien sind. Solange die Backup-Aufgabe (das sind dann üblicherweise mehrere Bilddateien in der Größenordnung um 10MByte) über rsync läuft, bricht der Downstream zusammen.

 

[sebr]

Ich werde es auch noch einmal mit mehreren kleinen Dateien versuchen.

Nur mal so eine Frage interessehalber: wieviel Upstream Kanäle nutzt deine Box aktuell?

 

[whale]

Habe nur einen Upstream-Kanal zur Verfügung, evtl. gibt es ja da Unterschiede.

 

[CapFloor]

Was heißt denn "größere Datei"? Ich lade gerade einige iso Images per rsync hoch zum Test. Es sind schon mehr wie 1GB problemlos über die Leitung gegangen...

@sebr:
Um hier Nachvollziehbarkeit zu gewährleisten, hier nochmal die Randbedingungen und die Tests:

Voraussetzungen:
1. Die hast einen 128MBit/s Anschluss?
2. Die Fritzbox zeigt nur für den RSYNC Upload allein eine volle Upstream Auslastung (min. 5,2MBit/s, besser 5,3MBit/s)?

Jetzt testen:
3. Du rufst eine Website (http) auf.
4. Du versucht ein Telefonat nach draußen zu führen.

Wenn das alles bei Dir zusammen funktioniert, hat Dein Anschluss das Problem nicht.

Viele Grüße
Frank

 

[Marks9156]

1. Die hast einen 128MBit/s Anschluss?
2. Die Fritzbox zeigt nur für den RSYNC Upload allein eine volle Upstream Auslastung (min. 5,2MBit/s, besser 5,3MBit/s)?
4. Du versucht ein Telefonat nach draußen zu führen.
Wenn das alles bei Dir zusammen funktioniert, hat Dein Anschluss das Problem nicht.

Das funktioniert schon.
Wenn ich aber wirklich 100% Auslastung im Upload habe, klingen die Stimmen beim Telefonat "abgehackt".
Meinst du das?

 

[sebr]

Achso, dass das Problem nur beim 128.000er Anschluss auftreten sollen wusste ich nicht (wurde das vorher schon mal erwähnt?!).
Dann sind meine Tests wohl nicht relevant für "dieses" Problem.

 

[CapFloor]

Ich habe das etwas versteckt erwähnt:

Da ich selbst einen 128MBit/s Zugang habe, weiss ich nicht, ob dieses Problem auch bei 64MBit/s Zugängen auftritt. Auch hier schaltet UM ja die "vollen" 5MBit/s Upstream frei.

@plauzi:
Nein, obwohl das mit den abgehackten Gesprächen auch nicht auftreten sollte.
Bei Volllast im Upstream mit rsync kannst Du also normal surfen (vielleicht nur etwas langsamer)? Dann existiert das Problem bei Dir nicht!

Viele Grüße
Frank

 

[Marks9156]

Was ist mit "rsync" gemeint?
Ich bin kein Anfänger, kann aber mit diesem Begriff nichts anfangen.

Kannst du mal bitte den Link nennen, indem dein(?) Problem möglichst exakt beschrieben ist.
Ich hatte schon oft Kontakt mit der UM-Technik in Kerpen, die sich auch jedesmal sehr bemüht hat, zu helfen und es letztlich auch immer hinbekommen hat.

 

[CapFloor]

Hier die Links zu den Wikipedia Einträgen bzgl. RSYNC, die sich im Deutschen und Englischen doch um einiges unterscheiden:

• 
  http://de.wikipedia.org/wiki/Rsync
  http://en.wikipedia.org/wiki/Rsync

Kurz gesagt: mit RSYNC kann man sehr effizient Dateisysteme zwischen zwei (weit entfernten) Standorten synchronisieren - eben auch über eher langsame Verbindungen (wie unsere Upstreams). Das gibt's schon lange unter UNIX, populär wurde es jetzt wieder beim Zusammenspiel /der Synchroinisation von (Home-)NAS Geräten und Cloud Daten-Diensten, wie Strato-HiDrive. Es ist ja gerade das perfide an dem beschriebenen Problem, dass es nur im Zusammenhang mit der Benutzung von RSYNC auftritt.

Die Problembeschreibung von @whale steht hier:
http://www.unitymediaforum.de/viewtopic.php?p=197909#p197909
Meine Nachfrage über die näheren Umstände, gefolgt von @whale's Antwort, hier:
http://www.unitymediaforum.de/viewtopic.php?p=198299#p198299
Meine Ausführungen dazu hier:
http://www.unitymediaforum.de/viewtopic.php?p=198406#p198406

Ich habe das Problem gar nicht mehr, da ich die FB gegen ein Modem eingetauscht habe. Aber ich habe das Fehlerbild vor dem Tausch eingehend analysiert und diese Informationen an @whale gegeben.

Viele Grüße
Frank

 

[DrBrain]

Hallo,

verstehe ich das richtig, AVM führt auf der Fritz!Box 6360 ohne ausdrücklichen Wunsch des Benutzers Traffic-Shaping durch und reduziert dadurch die maximal zur Verfügung stehende Bandbreite?
Ist das Hörensagen oder gibt es dafür einen Beleg? Wäre interessant zu wissen

Grüße

..na, so kann man das nicht sagen. Traffic-Shaping ist eine gute Methode, um den anfallenden Datenverkher so zu koordinieren, dass sich Down- und Upload nicht gegenseitig behindern.

Guter Artikel:
http://de.wikipedia.org/wiki/Traffic-Shaping

Zitat:
-------------------------------------------------

Das Traffic-Shaping analysiert nun den anfallenden Datenverkehr in beide Richtungen und priorisiert die Datenpakete so, dass Uploads die DSL-Strecke nicht mehr überlasten und Downloads sich nicht gegenseitig behindern. Dies bringt folgende Vorteile:

volle Download-Rate trotz Uploads
volle Download-Rate bei mehreren Downloads und Uploads
responsives Verhalten beim Surfen (bessere Ping-Zeiten, wichtig beispielsweise bei Onlinegames)
--------------------------------------------------------
Zitat Ende:

Und weiter:

Zitat:
----------------------------------------------------
Die Firma AVM bietet Traffic Shaping in ihren Fritz!Box DSL-Modem Lösungen an, ebenso die Telekom mit einigen ihrer Speedport Modemroutern. Weitere Systeme stammen von der Firma Packeteer Inc. in Cupertino, USA. Diese "PacketShaper" werden als eigenständige Appliance zum Bandbreiten- und Qualitätsmanagement verwendet. Auch Systeme von Sandvine/Ellacoya Systeme oder die Cisco SCE 1000 Serie kommen zum Einsatz. Diese sind in der Lage, den Dateninhalt der Pakete zu analysieren (sniffen). Weitere Hersteller sind beispielsweise Expand, Sitara Networks und Allot Inc.
-----------------------------------------------------
Zitat Ende:

AVM nennt es "Traffic-Shaping".....andere Router Hersteller verstecken es einfach under "QoS" (Quality Of Service)

Ganz gut - um sich das mal zu Veranschaulichen ist hier diese Seite:

http://www.cfos.de/en/traffic-shaping/traffic-shaping.htm


Dr.Brain

 

[whale]

128MBit/s ist keine Vorraussetzung, denn ich habe einen 32MBit/s-Anschluss und die gleichen Probleme.
Bei mir hilft übrigens der Trick von CapFloor mit der Annahme des eingehenden Telefonats auch nicht, denn nach einiger Zeit des belegten Upstreams sind die Telefonnummern nicht mehr erreichbar. Die FB bringt entsprechende Fehlermeldungen:
"Anmeldung der Internetrufnummer (<Rufnummer>) war nicht erfolgreich. Ursache: DNS-Fehler" und
"Anmeldung der Internetrufnummer <Rufnummer> war nicht erfolgreich. Gegenstelle meldet Ursache 404"

 

[MediaMan]

Habe DSL 32.000 mit Telefon Plus und eine ähnliche Erfahrung gemacht. Während einer Teamviewer-Session mit Dateiupload auf den Fremd-PC gab es einen erheblichen Qualitätsverlust bei der Telefonie. Mein Gesprächspartner sagte, ich würde mich anhören wie durch einen Zerhacker gejagt. (War wohl der sog. Fritz!Scrambler... :brüll: ). Auf meiner Seite (Downstream) gab es keine Probleme.

Scheinbar hat man das Problem noch immer nicht 100% im Griff. Ähnliche Probleme hatte ich schon mit der 7170.

Ganz ehrlich? Ich trauere meinem Euro-ISDN Anschluss nach. 10 Jahre Telefonie ohne Probleme.

Ich frage micht ernsthaft, wer die ausgerollte Fritzbox Firmware bei UM testet. Erst wird ein Staatsgeheimnis daraus gemacht und einem was von Qualitätskontrolle erzählt, aber trotzdem enthält die Firmware kapitale Fehler, die schon nach ein paar Betriebsstunden jedem "Laien" auffallen. :sauer:

 

[Joerg123]

Habe DSL 32.000 mit Telefon Plus und eine ähnliche Erfahrung gemacht. Während einer Teamviewer-Session mit Dateiupload auf den Fremd-PC gab es einen erheblichen Qualitätsverlust bei der Telefonie.

Da ich in der Richtung eigentlich nie Probleme festgestellt habe, meine Fritzbox Telefonie stark/ausreichend bevorzugt, könnte ich mir vorstellen, dass du den lokalen PC, welcher für die Teamviewer-Sitzung genutzt wurde, in den Interneteinstellungen > Filter > Priorisierung als "Echtzeitanwendung" parallel zur Telefonie bevorzugst ?! eventuell auch nicht "einfach nur den PC/Netzwerkanwendung beliebig", sondern die vom Teamviewer genutzten Ports.
Netzwerkanwendung "Internettelefonie" + "Gerät = automatisch" sind dort als Echtzeitanwendung zumindest auch eingetragen ?
Dann wäre es zumindest verständlich, weshalb Telefonie gegenüber Teamviewer nicht bevorzugt wird und die Qualität des Telefonats sinkt. Wie gesagt scheint bei mir die Priorisierung gut zu funktionieren, auch das Versenden grosser Mails, oder FTP-Upload sogar von einem PC der unter "priorisierte Anwendungen" (Anwendung beliebig) eingetragen, stört bei mir nicht die Telefoniequalität auch wenn die Leitung/Upload dabei voll ausgelastet ist. War auch schon bei 32MBit/s + 1MBit/s Upload so.
Im Zweifelsfall, wenn das nicht funzt, würde ich mal unter System die Einstellungen speichern > Werksreset machen und dann erneut testen, ob das Traffic-Shaping nun funzt (falls es nichts gebracht hat kannst du ja deine Sicherung wieder einspielen, asonsten wäre halt von Hand neu konfigurieren angesagt.