FRITZ!Box 7490 Labor-Firmware FRITZ!OS 6.69-41756 (01.11.2016)

Keinerlei Probleme, Radio, WLAN, ADSL-Sync, alles top.
 
Vollsync wieder im Download, aber der Upload ist immer noch so mies. Leitungskapazität in beiden Richtungen gefallen. Das komische ist immer, daß direkt nach dem Sync die Leitungskapazität im Upload als auch im DL ansteigt. Wobei im Download gerade mal die 109000 erreicht werden und im Upload 38700. Danach springt die Leitungskapazität im Upload direkt auf über 42000. Nur der Sync ist schlecht. Im DL steigt sie um ca. 1000 auf nur noch 11000kbit. Von dne hervorragenden 130000kbit Leitungskapazität in einem Beta Treiber von der Labor der 6.5er FW bis zur jetzigen Labor ist jeder Treiber schlechter geworden. Mit dem Broadcom 164.97 wird AVM nicht richtig warm.
 
Keine Probleme mit dieser Version, Wlan, Sync, Streaming, Repeater usw. alles läuft.
 
Ich finde es immer wieder faszinierend, wie mancher auf die Werte für die "theoretische Leitungskapazität" abfährt ... das Problem ist nur, daß das eben ein höchst dynamischer Wert ist.

Im gewisser Weise wird ja beim Vectoring das Kabelbündel auch zu einem "shared medium", wie es bei DOCSIS und LTE der Fall ist (wenn dort auch eher die Datenübertragung als Multiplex mit "shared" gemeint ist, weil nur einer gleichzeitig senden kann) - beim Vectoring wird ja gezielt die eigentlich schädliche Induktion von Fremdspannungen bei gleichzeitiger Signalübertragung auf zwei benachbarten Leitungen (das "Übersprechen") ermittelt und bei der Übertragung berücksichtigt, ggf. sogar gezielt ausgenutzt. Sicherlich kann sich fast jeder noch aus der Schule an die Effekte erinnern, die beim Überlagern zweier Wellen (auch elektromagnetischer) entstehen können - das reicht von der Verstärkung bis zur kompletten Auslöschung, je nach "Phasenlage". Damit das gezielte Ausnutzen möglich ist, muß auf der Seite der VSt. der Zugriff auf alle Doppeladern in diesem Kabelbündel möglich sein, daher auch nur ein "Provider" für den Strang.

Wird jetzt auf mehreren Leitungen gleichzeitig gesendet, nimmt natürlich auch das Übersprechen zwischen verschiedenen DA zu und es können davon betroffene Frequenzen aktuell nicht für die Übertragung benutzt werden. Anders als ohne Vectoring werden die dann aber eben "ausgeblendet" und nicht verwendet (oder - wenn möglich - die Signale durch Phasenverschiebung so angepaßt, daß kein Datenverlust auftritt), damit werden die ansonsten dort übertragenen "Bits" nicht verfälscht und deren Übertragung muß nicht wiederholt werden - was den möglichen Durchsatz insgesamt begrenzen würde. Man kann ja mal spekulieren, daß der am Beginn immer wieder beobachtete permanente Rückgang der "Leitungskapazität" damit zusammengehangen hat/haben könnte, daß solche "aussortierten" Frequenzen dann später nicht wieder genutzt wurden und so mit jeder temporär nicht nutzbaren Frequenz die Gesamtkapazität sank.

Der tatsächlich zu erzielende Durchsatz im Moment einer Übertragung hängt also ohnehin davon ab, wieviele und sogar welche Nachbarn gleichzeitig Daten übertragen wollen. Wenn beim Training gleich von Beginn an einige Frequenzen als untauglich ausgesondert werden, dann sind das (vermutlich) welche, die ohnehin nur in den seltensten Fällen für die reibungslose Übertragung wirklich genutzt werden können, weil sie gleich am Beginn zu "noisy" sind - schon die Entscheidung für den richtigen "Schwellwert", ab dem eine solche Frequenz dann nicht in Betracht gezogen wird, dürfte nicht so ganz einfach sein. Eine Synchronisation ohne solche Wackelkandidaten kann jedenfalls sogar besser sein und am Ende einen höheren, effektiven Durchsatz ergeben als eine, die nur auf den höchsten theoretischen Durchsatz schielt und dann auf den "unsicheren" Frequenzen die Übertragung wiederholen muß, weil dort das Nutzsignal im Rauschen untergegangen ist.
 
Mein Rechner heißt plötzlich Avira, obwohl der Rechner nicht so heißt, der Ping dahin ins Leere läuft und ich auch keinen Virenscanner namens Avira habe...
 
Die FRITZ!App Fon läuft 1A, was läuft den nicht???
 
Hier am Broadcom 176.29 kein VDSL-Sync mit Treiber 1.100.135.11 möglich. Blöd, ich dachte AVM hätte es inzwischen im Griff... :(
Mit Treiber 1.100.135.10 der letzten Labor lief VDSL100 nahezu fehlerfrei. Da hatte ich gerade mal 50 Sekunden mit Fehlern in 2 Wochen!
 
Auch wenn auf mein am 27.10. gepostetes Problem mit Fritz!App Fon keinerlei Reaktion aus dem Forum kam, möchte ich zumindest mitteilen, dass dieses Problem auch unter der aktuellen Beta weiterhin vorhanden ist.

Aber immerhin funktioniert jetzt der Zugriff auf Fritz!NAS wieder, so dass ich meinen AB mit der "Telefon-SPAM-Bremse" (... kein Anschluss unter dieser Nummer ...) einrichten konnte.
Der Mensch freut sich auch über kleine Erfolge.

MfG Peter

Vielleicht unter "Eigene Rufnummern/Anschlusseinstellungen" den Haken "bei Nutzung von Internettelefonie aus dem Heimnetz unterbinden" gesetzt?
 
Der tatsächlich zu erzielende Durchsatz im Moment einer Übertragung hängt also ohnehin davon ab, wieviele und sogar welche Nachbarn gleichzeitig Daten übertragen wollen.
Wie das? Soweit mir bekannt, handelt es sich bei VDSL2 um eine synchrone Übertragungstechnik - da werden unablässig 4000 DMT-Symbole pro Sekunde auf die Leitung gegeben, egal, ob irgendjemand tatsächlich Daten übertragen will oder nicht. Wenn keine zu sendenden Daten zur Verfügung stehen, werden eben leere 64/65-Frames auf die Reise geschickt. Und ein Scrambler sorgt dafür, dass dann nicht etwa nur Nullbits, sondern ein schön gleichmässiges "Rauschen" auf der Leitung ist.

Ergo müssten die gegenseitigen Beeinflussungen der Leitungen völlig unabhängig davon sein, ob da irgendjemand tatsächlich Daten übertragen will.

Oder habe ich da einen Mechanismus übersehen?
 
Wenn es bei VDSL2 tatsächlich ein Framing gibt (wie bei ISDN, da halt mit geringerer Frequenz/Framesize) und permanent zufällige Daten übertragen werden, dann bin ich meinerseits im Irrtum - ich gebe zu, daß ich da nur auf theoretische Überlegungen zum FEXT gebaut habe und mir solche ständigen Übertragungen zufälliger Daten gar nicht geläufig waren bzw. es immer noch nicht sind. Hinzu kommt noch die propagierte Abwärtskompatibilität zu ADSL2+ ... gibt es dort dann auch ein solches "framing"? In der Regel interessiert mich das erst hinter dem Modem beruflich ... der Rest ist Physikunterricht und (lange vergangenes) Interesse an Elektronik allgemein.

Soweit ich das kenne bzw. gelesen habe, gibt es beim Vectoring (meintest Du vielleicht auch VDSL2-Vectoring?) zwar eine permanente Störsignalmessung, die findet aber nur auf einigen, verteilten Bins statt und verwendet auch vordefinierte Muster für die Störungserkennung und kein "Rauschen". Der letzte Absatz von mir im angesprochenen Beitrag sollte sich (ich habe das sicherlich nicht deutlich genug gemacht) auch auf Anschlüsse ohne Vectoring beziehen, weil ich auch die (immer wieder gerne genommenen) manuellen Veränderungen von SNR-Vorgaben im Blick hatte, die am Ende auch nur dazu führen, daß "schlechtere" Bins mit einbezogen werden oder mehr Symbole auf so einen Träger moduliert werden, die dann am Ende nicht mehr sauber ankommen und so den Durchsatz sogar negativ beeinflussen können.

Ich habe im Moment keine Zeit (und auch keine wirkliche Lust), bei der ETSI oder beim Breitbandforum ausführlich in G.993.5 nachzulesen, aber zumindest in einer "Übersicht" zum Vectoring heißt es beim Broadband-Forum (in Punkt 4.7):
4.7 Addition and removal of VDSL2 signals on other lines

VDSL2 signals may appear and disappear at any time due to addition or removal of service, power failure, or a customer turning their modem on or off. Since it will take some time for the vectoring function to learn the new FEXT, the vectoring process must be designed to assure that errors do not occur in these situations.


-Hieße ein permanentes Framing auf allen Bins dann in der Konsequenz nicht auch, daß der Stromverbrauch beim VDSL2 so richtig durch die Decke geht?

Wenn es sich bei "der Leitung" um die DA jedes einzelnen Kunden handelt und da ständig auf allen verwendeten Bins volles Ballett ist (das Maß des Übersprechens - nicht nur beim FEXT - ist ja frequenz- und pegelabhängig), dann müßte der Energieverbrauch eines DSLAM und des Modems ja immer bei 100% sein (mal nur den "Verbrauch" auf den Leitungen betrachtet, nichts was das Equipment ansonsten noch verbraucht, wenn es nicht "im Leerlauf" ist) ... oder wo bin ich hier im Irrtum?

Ist das tatsächlich so? Dann ergäbe sich eine (relativ) konstante Charakteristik der Leitung (nur durch eher seltene Spikes von anderen Störern ggf. beeinflußt und auch dafür gibt es die Fehlerkorrekturmechanismen aus den älteren Verfahren noch) und ich läge falsch mit der Annahme, daß das von mir Geschriebene für jede einzelne Datenübertragung und den Moment der Übertragung gilt und es stünde immer die volle (nach dem Training ausgehandelte) Kapazität aller Bins zur Verfügung.

Dann ist das unabhängig von der Nutzung anderer DA, solange sich das "Leitungsbild" nicht ändert, weil z.B. eine DA dazugeschaltet wird, wenn ein Modem beim Kunden eingeschaltet oder neu gestartet wird - spätestens da sollte sich das jedenfalls nach dem o.a. Link ändern und damit ist das immer noch das "dynamische" Verhalten einer solchen Synchronisation, das ich eigentlich thematisieren wollte.

Oder liegt da gar ständig auf allen DA (egal, ob da gerade am anderen Ende beim Kunden ein Modem arbeitet oder nicht) dieses absichtliche "Rauschen" an? Was passiert mit der Leitung, wenn sich - durch An- oder Abstecken eines Endgerätes von der TAE-Dose - deren Länge ändert und damit ja auch die Charakteristik des Signals auf dieser DA, weil Reflektionen jetzt an einer anderen Stelle entstehen?

So ein "offenes Kabelende" an einem APL liefert (zumindest theoretisch) noch einmal ganz andere Reflexionen des eingespeisten Signals, denn es fehlt ja "der Verbraucher" und die eingespeiste Energie "verschwindet" ja nicht einfach. Gibt es dann noch andere Vorkehrungen, um solche Reflexionen zu vermeiden? Ich wüßte nicht, daß die Telekom sämtliche APL an einem Vectoring-Kabel mit Abschlußwiderständen ausstattet - und mir fehlt auch die Idee, ob man die "zurückfließende Energie" tatsächlich erneut nutzen könnte. Aber daß sich die Charakteristik einer DA anders darstellt, wenn da am anderen Ende ein Transceiver sitzt und das eingespeiste Signal nicht (ungedämpft, außer durch die Leitungsverluste) als Reflexion wieder beim Sender ankommt, würde für mich nicht in Frage stehen - schon durch diese Reflexion würde sich die Amplitude des Signals in Abhängigkeit von der Phasenlage von Original und Reflexion ändern oder nicht?

Ich bin also ziemlich verblüfft, wenn auf einem VDSL2-Kabel (mit oder ohne Vectoring, das Schielen auf die "Leitungskapazität" gilt ja auch für Anschlüsse ohne Vectoring) tatsächlich immer eine Datenübertragung auf allen DA stattfindet und seien es nur zufällige Daten als "Rauschen" - andererseits schafft so eine konstante Umgebung ja auch erst die Möglichkeit, sich auf die Besonderheiten jeder DA einzustellen ... aber daß tatsächlich auf allen (auch ungenutzten oder sogar offenen) DA immer mit demselben Pegel gesendet wird, kann ich mir fast nicht vorstellen (das muß aber auch nichts heißen und ich habe mir zumindest mal vorgenommen, mir die Spezifikation für G.993.5 in voller Schönheit anzutun - aber wohl nicht mehr in diesem Jahr).
 
Es soll auch Energiesparfüchse geben, die bei Abwesenheit (Arbeitszeit-outdoor/Urlaub/Nachtschlafenszeit) ihre FB/Router einfach "vom Strom" nehmen? <Abduck> ... ich kenne wirklich persönlich einige solcher Zeitgenossen, die das "cool" finden! ... Belehrung hoffnungslos! Versäumte Anrufe/AB juckt die nicht ... können ja gefälligst anrufen wenn zuhause und wirklich wichtig :D
LG
 
Zuletzt bearbeitet:
Wenn es bei VDSL2 tatsächlich ein Framing gibt (wie bei ISDN, da halt mit geringerer Frequenz/Framesize) und permanent zufällige Daten übertragen werden,
Den "wie bei ISDN" synchronen Kanal mit permanenter Bitrate gibt es tatsächlich bei ADSL*/VDSL*, und diese Bitrate zeigt einem die Fritz!Box unter "Aktuelle Datenrate" in den DSL-Informationen an.

Auf der Ebene darunter wird bei VDSL2 4000 mal pro Sekunde ein neues Frequenzmuster auf der Leitung gesendet - ein DMT-Symbol, mit variabler Bitzahl pro Träger. Darauf setzt der Scrambler auf (um Effekte durch ungünstige Bitmuster zu verhindern) und dann ein "Framing", welches Reed-Solomon Codeworte auf die verfügbaren Trägerbits mappt. Beim Training wird dieses Framing so berechnet dass - sofern die physikalischen Eigenschaften der Leitung es hergeben - nach Dekodieren dieser Codeworte als dessen Nutzinhalt eben die "Aktuelle Datenrate" übrig bleibt - sofern die Reed-Solomon Codeworte auf Empfangsseite erfolgreich rekonstruiert werden können, ansonsten gibt es natürlich temporäre Einbussen der Datenrate. In den DMT-Symbolen werden also deutlich mehr Bits übertragen.

Auf der Ebene darüber muss eine "Kapselung" erfolgen, damit über den synchronen Kanal einzelne Ethernet-Frames übertragen werden können. Bei ADSL* wurde da noch eine ATM-Schicht verwendet, in die dann Ethernet-Frames verpackt wurden - höchst verschwenderisch, denn für einen Ethernet-Frame mit 1500 Bytes Payload mussten dann 1696 Bytes auf den synchronen Kanal gegeben werden. Mit VDSL2 wurde der erheblich effizientere PTM (Packet Transfer Mode) mit 64/65 Kapselung eingeführt, der für die gleiche Ethernet-Payload nur noch ca. 1550 Bytes auf dem synchronen Kanal benötigt. PTM wurde zwar noch nachträglich für ADSL2 spezifiziert, findet in Deutschland m.W. aber nur bei VDSL2 Anwendung.

Und in dieser 64/65 Kapselung werden, wenn es keine Ethernet-Frames zu übertragen gibt, eben "Idle-Codeworte" übertragen, siehe hier Folie 6 ganz unten:

http://www.ieee802.org/3/efm/public/jan03/copper/omahony_copper_1_0103.pdf

Aufgrund des darunter liegenden Scramblers führt das immer gleiche Idle-Codewort aber eben nicht zu den gleichen DMT-Symbolen.

In der Regel interessiert mich das erst hinter dem Modem beruflich ... der Rest ist Physikunterricht und (lange vergangenes) Interesse an Elektronik allgemein.
Von der Physik ist man da noch weit entfernt. Alles oben Beschriebene ist ja dann doch eher noch Informationstechnik...

Soweit ich das kenne bzw. gelesen habe, gibt es beim Vectoring (meintest Du vielleicht auch VDSL2-Vectoring?) zwar eine permanente Störsignalmessung, die findet aber nur auf einigen, verteilten Bins statt und verwendet auch vordefinierte Muster für die Störungserkennung und kein "Rauschen".
Bei VDSL2 wird alle 256 DMT-Symbole ein "Synchronisations-Symbol" eingeschoben (Anekdote am Rande: Im Gegensatz zu ADSL wird bei VDSL2 dieses Symbol nicht durch eine etwas höhere Symbolrate kompensiert, sodass bei der Berechnung des "Framings" der Faktor 256/257 einbezogen werden muss - was den Ingenieuren bei Infineon aber wohl keiner gesagt hat, denn die haben ihn vergessen, wodurch die erste Generation von VDSL2-DSLAMs und Modems in Deutschland tatsächlich nur ein 256/257-tel der angestrebten und angezeigten Datenrate lieferte, was später u.a. dadurch auffiel, dass ein Infineon-Modem an einem Broadcom-DSLAM meinte, der hätte den Upstream auf 10080kbps synchronisiert - dabei hatte der lediglich das korrekte Framing für 10048kbps berechnet). Dieses Synchronisations-Symbol kodiert bei Standard-VDSL2 nur Nullbits als Referenz (ohne Scrambling). Bei Vectoring kann das Kundenmodem angewiesen werden, dort andere Bitmuster zu kodieren, was dem DSLAM beim ständigen Ausmessen der gegenseitigen Störungen helfen soll. Ob das auch im Downstream zum Einsatz kommt, ist mir gerade nicht geläufig.

Hieße ein permanentes Framing auf allen Bins dann in der Konsequenz nicht auch, daß der Stromverbrauch beim VDSL2 so richtig durch die Decke geht?

Wenn es sich bei "der Leitung" um die DA jedes einzelnen Kunden handelt und da ständig auf allen verwendeten Bins volles Ballett ist (das Maß des Übersprechens - nicht nur beim FEXT - ist ja frequenz- und pegelabhängig), dann müßte der Energieverbrauch eines DSLAM und des Modems ja immer bei 100% sein (mal nur den "Verbrauch" auf den Leitungen betrachtet, nichts was das Equipment ansonsten noch verbraucht, wenn es nicht "im Leerlauf" ist) ... oder wo bin ich hier im Irrtum?

Ist das tatsächlich so? Dann ergäbe sich eine (relativ) konstante Charakteristik der Leitung
Genau deshalb ist das so. Bei ADSL2 hat man mal Stromsparmodi eingeführt ("L2" nannte sich das, wenn ich mich richtig erinnere), und das hat - soweit ich das mitbekommen habe, ich selbst bin aufgrund zu langer DA nie in den Genuss von ADSL2 gekommen - erhebliche Probleme veruracht, weil es ständig die Charakteristik des Leitungsbündels veränderte. Soweit ich weiß, hat die Telekom das schon lange überall wieder abgeschaltet.

Oder liegt da gar ständig auf allen DA (egal, ob da gerade am anderen Ende beim Kunden ein Modem arbeitet oder nicht) dieses absichtliche "Rauschen" an?
Nein, natürlich nicht. Das "Rauschen" gibt es erst nach Training/"Synchronisierung", wenn der synchrone Kanal steht.
 
Zuletzt bearbeitet:
Wow, hier haben sich ja Zwei gefunden. Respekt.
 
Fakt ist, daß AVM mit dem VDSL Treiber an Broadcom Outdoor DSLams anscheinend Probleme hat. Nur werden diese fast ausschliesslich von der Telekom eingesetzt. Und die Telekom hat die meisten Vectoring Anschlüsse in Deutschland. Auch 1&1 und Vodafone kaufen da ihren Bitstrom ein. Deswegen verstehe ich es nicht weshalb der Treiber von Version zu Version schlechter wird. Bei unter 100m Leitungslänge sollte man in beiden Richtungen immer Vollsync haben. So wie man hier aber liest konzentriert sich AVM anscheinend momentan darauf an weiter entfernten Anschlüssen den Durchsatz zu erhöhen. Es kann ja nicht sein, daß ein Speedport einen besseren Sync bekommt als eine FB 7490.
 
Ich habe gerade dieses update gemacht und die schlechtesten Werte bekommen, 80down 30up! Jetzt bin ich zurück auf die 41222, die letzte Version, die ich noch als Image hatte. Werte jetzt aber auch nicht gut. Wäre ich doch nur bei der 41670 geblieben, da waren die Werte noch super gut. Kann mir jemand sagen, wie ich an dieses Image komme?

Habs jetzt hinbekommen, nach Einspielen und Powerreset alles wieder gut mit der 41670. Und bei der bleibe ich auch.
 
Zuletzt bearbeitet:
Auch hier wieder nur [piiieeeppp] !

Fritz Dec200 gekauft heute angemeldet, bleibt es aber n ur 5 minuten danach Blinkt Fritz Dec200 nur noch und das wo sie erfolgreich verbunden war.
Konnte auch in der Benutzeroberfläsche diesen auch sehen.

Das regt mich schon auf so was .
 
Zuletzt bearbeitet von einem Moderator:
Hey was soll das?
Das ist eine LABOR-Firmware.
Wieder ein Spielkind? Wenn dich das aufregt, lass die Laborreihe und bleibe bei den Stables.
Die Laborreihe ist dafür da um vor dem offiziellen Rollout die FWs in einem breiten Umfeld zu testen.
Also gebe AVM ein Feedback in einem vernünftigen Tonfall.
 
Nach 24 Stunden sehr hohe Download Datenrate. 1.100.135.11 macht sich am Vectoring Port Broadcom 164.97 besser als der Vorgänger 135.10. (Bei dem waren es 5-6 Resyncs pro Tag)

Keine Resyncs während des Tages.
 
... bleibt es aber n ur 5 minuten danach Blinkt Fritz Dec200 nur noch und das wo sie erfolgreich verbunden war .
Passiert das immer wieder? D.h. du meldest an, dann verliert die fritzbox die Verbindung, dann meldet du wieder an, ...? Ist die Entfernung vielleicht im Grenzbereich?
 
Passiert das immer wieder? D.h. du meldest an, dann verliert die fritzbox die Verbindung, dann meldet du wieder an, ...? Ist die Entfernung vielleicht im Grenzbereich?
Das kann nicht an der Entfernung liegen, ich habe direkt neben der Fritzbox vielleicht 10 cm stehen/stecken damit ich sie Anmelden kann.

Dec 200 rein, sie Blinkt Dec
10sek FritzBox Dec gedrückt Info anzeige blingt.
Paar Sekunden Später ist Dec an der FritzDec200 dauerhaft an.

Gehe kurz Weg um zu schauen ob sie in der FritzBox zu sehen ist, Ja.
Gehe zurück ins Wohnzimmer Blinken beide LED die ganze zeit
 

Zurzeit aktive Besucher

Statistik des Forums

Themen
246,197
Beiträge
2,247,888
Mitglieder
373,755
Neuestes Mitglied
grdex
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.