Beiträge von jan

gponner Mir ging es eigentlich auch nur um die Aussage, dass jeder ONT in jedem Frame eine Sendegelegenheit bekommt. Und dafür finde ich den ITU-Recommendations keine Quelle. Der OLT kann die Upstream-Bursts innerhalb eines Frames beliebig verteilen, und muss dabei nicht alle ONTs (bzw. Alloc-IDs) berücksichtigen. Außerdem gibt es für jeden Frame eine neue BWmap, d.h. die Zuordnung kann sich auch ständig ändern.

Falls ich da was falsch verstanden habe, würde ich mich sehr freuen, wenn du mir sagst, wo genau der Fehler liegt.

Ich habe mir auch das Ericsson-Paper nochmal etwas genauer angeschaut: Da wurde angenommen, dass jeweils einmal pro Polling-Intervall innerhalb von einem einzigen Frame die Bandwidth-Reports von allen ONTs abgefragt werden. Konkrete Details zur Zuweisung in den restlichen Frames (in diesem Modell) gehen daraus aber nicht wirklich eindeutig hervor.

Dafür habe ich noch etwas mehr Lesestoff gefunden, wo auch neuere PON-Standards untersucht werden:

• Understanding Latency across PON systems (With few comparisons to DOCSIS systems) (2022)
• Bandwidth and Latency Analysis of 25GS PON - An Overview of 25GS Passive Optical Networks (2022)

Zitat von gponner

Auch bzgl. der Latenzen hat das GPON Protokoll viele Vorteile. Aufgrund der 8 KHz Taktung der Up- und Downstream-Frames hat jeder Teilnehmer am PON 8000 mal pro Sekunde die Chance ein Paket loszuwerden bzw. zu bekommen. Das Protokoll lässt nicht zu, dass ein Teilnehmer einen kompletten PON nur mit seinen Daten sättigt! 8000 mal pro Sekunde wird jeder Teilnehmer auf jeden Fall bedient.

Man könnte sicher jedem ONT in jedem Frame eine Sendemöglichkeit geben, aber die Frage ist ob das wirklich sinnvoll ist. Vorgeschrieben ist es soweit ich sehe ja gerade nicht, der OLT hat die volle Kontrolle über die Zuteilung. Und in dem verlinkten Dokument von Ericsson wurden ja Polling-Intervalle im Bereich 0,5-3,5 ms untersucht.

Jeder Upstream-Burst hat einen Overhead von 19 Bytes (2 Bytes TX-Enable + 2 Bytes TX-Disable + 12 Bytes Guard/Preamble/Delimiter + 3 Bytes Burst Header). Ein Upstream-Frame hat 19440 Bytes. Damit blieben gleicher Verteilung auf 32 Teilnehmern rein rechnerisch jeweils 588,5 Bytes für die Nutzdaten (wobei der GEM-Overhead, und evtl. Management-Daten noch nicht berücksichtigt ist).

Klingt jetzt tatsächlich erstmal nicht nach so einem riesigen Overhead (evtl. habe ich auch was übersehen). Aber ich bin trotzdem nicht überzeugt, dass eine Polling-Rate von 0,125ms sinnvoll wäre.

HubeBube Das Zitat des Pressesprechers der Bundesnetzagentur stammt aber aus dem aktuellen Artikel, und bezieht sich sogar direkt auf die neue Entscheidung. Das ist demnach also die aktuelle Position der Bundesnetzagentur.

Zitat von GlasfaserFORUM

- gem. TKG ist die Inhouse-Verkabelung Vermietersache, er kann dies aber über das Glasfaserbereitstellungsentgelt auf mich als Mieter umlegen (60€ jährlich)

Bietet der Netzbetreiber überhaupt die Inhaus-Verkabelung gegen ein Glasfaserbereitstellungsentgelt an? Denn selber berechnen darf der Vermieter das nicht, erlaubt ist nur die Gebühren vom Netzbetreiber 1:1 durchzureichen.

Zitat von DLMttH

Soweit ich weiß, kannst du aktuelle 1&1-Boxen nicht einmal debranden.

Genau so ist es. Ein Provider-Additive lässt sich wie oben von Lozuopbro beschrieben entfernen. Die 1&1-Boxen haben aber ein richtiges Branding, und das kann man nicht ohne weiteres entfernen. Das wird über die Variable "firmware_version" gesteuert, die sich über den Bootloader nicht (mehr) dauerhaft ändern lässt.

Aber letztendlich gibt es dadurch keine nennenswerten Einschränkungen außer dem Einrichtungsassistenten von 1&1, und den kann man ja einfach überspringen.

Normalerweise sollte für DS-LIte unter OpenWrt keine zusätzliche Konfiguration nötig sein. Es muss nur das Paket "ds-lite" installiert sein. Sobald über DHCPv6 der AFTR bekannt ist, wird dann automatisch ein dynamisches Interface für den Tunnel angelegt.

Manuell ein Interface für DS-Lite mit option peeraddr '::' zu konfigurieren (wie es im OpenWrt-Wiki steht, und wohl auch im verlinkten Thema zuerst versucht wurde) ist nicht sinnvoll. Es gibt keinen Code der diesen Wert irgendwie speziell behandeln würde, das ist also einfach nur eine ungültige Konfiguration. Man müsste dann schon die richtige AFTR-Adresse angeben (und am besten auch das eigentliche WAN-Interface um option iface_dslite '0' ergänzen, um die Autokonfiguration zu deaktivieren).

Der Name ist "teranet", das X ist bloß ein ungünstig gestaltetes Logo.

Einige Ausbaugebiete der GVG (das ist die Firma hinter Teranet) wurden jetzt nach längerem Stillstand an die UGG übergeben. Teranet als Anbieter im UGG-Netz ist deshalb wohl auch nur in diesen Gebieten verfügbar.

Bei einem der betroffenen Gebiete hier in der Nähe wird auf der Gebietsseite bei der UGG als Anbieter auch Teranet mit aufgelistet.

Zitat von ConiKost

Weißt du eigentlich, ob man auf mobilen Geräten in der Google und Apple Welt auch einen statischen Interface Identifier setzen kann?

Unter Android gibt es wohl keine Möglichkeit, den Interface Identifier manuell zu setzen.

Im WLAN wird EUI-64 genutzt, wenn die Verbindung mit zufälliger MAC-Adresse konfiguriert ist. Bei Nutzung der Geräte-MAC-Adresse wird stattdessen eine Stable-Privacy-Adresse vergeben. In beiden Fällen werden zusätzlich temporäre Adressen genutzt (Privacy Extensions).

Wenn man also will, dass der Interface Identifier unabhängig vom Präfix gleich bleibt, muss man die WLAN-Verbindung mit zufälliger MAC-Adresse konfigurieren (die zufällige MAC-Adresse ist bei Android standardmäßig persistent, und ändert sich nicht regelmäßig).

Zitat von HubeBube

Android und Chromebooks kennen gar kein DHCPv6!

Das ist nur fast richtig: Android unterstützt mittlerweile tatsächlich DHCPv6, allerdings nur als Fallback, und auch nur Prefix Delegation. Also in der Praxis ziemlich nutzlos.

Die Änderung wurde in einem Update für Android 14 eingeführt, aber da der Netzwerk-Stack seit Android 10 über Mainline aktualisierbar ist, geht es auch bei älteren Geräten.

Zitat von HubeBube

Warum hat eine 5530 die HW Revision 257, obwohl sie nur den Falcon Prozessor (Modemteil) beinhaltet?

Ich verstehe die Frage nicht ganz. Geht es dir darum, dass sich die HW-Revision der 5530 von der des Modemteils der 5590 unterscheidet? Das wird wohl einfach daran liegen, dass es zwei verschiedene Geräte sind.

Es ist ja grundsätzlich schon richtig, dass jede Fritzbox bzw. Hardwarevariante eine eigene eindeutige HW-Revision hat. Die 5590 besteht halt im Prinzip intern aus zwei verschiedenen Geräten, auf denen jeweils eine separate Version vom FritzOS läuft.

Das Nummerierungsschema scheint einfach chronologisch zu sein, wenn man mal die Liste bei BoxMatrix durchgeht.

Zitat von HubeBube

Kennst Du ein unter Windows lauffähiges Tool, welches mir vergleichbar mit fritz_tffs_read die Key/value Paare ausliest? Bitte als Windows exe.

Da kann ich dir leider nicht weiterhelfen. Hier funktioniert das nichtmal mit fritz_tffs_read (getestet mit einer 7530). Ich vermute mal das liegt daran, dass bei Geräten mit NAND-Flash eine andere TFFS-Variante benutzt wird, die fritz_tffs_read nicht versteht.

Möglicherweise wäre es eine Idee fritz_tffs_nand von OpenWrt anzupassen, sodass es eine Datei lesen kann statt direkt von einem MTD-Gerät zu lesen. Das funktioniert jedenfalls auf einer 7520 mit OpenWrt einwandfrei.

Zitat von HubeBube

Boxmatrix führt 273 und 272 auf: https://boxmatrix.info/wiki/FRITZ%21Box_5590_Fiber

Scrolle runter zu den Firmware-Scans: Die "Fritz_Box_HW272" findest du hier nur bei der Software für den Hauptprozessor, und die "Fritz_Box_HW273" nur bei der vom Modem.

Das ist bei AVM bei Geräten mit mehreren SoCs so üblich, dass jeder Teil seine eigene HW-Revision hat. Lässt sich auch überprüfen, wenn man die Firmware selber entpackt, oder sich mal in den Open-Source-Archiven umschaut.

Zitat von HubeBube

5590: 272,273

Das sind in dem Fall aber keine verschiedenen Versionen der Fritzbox, sondern nur die zwei getrennten SoCs, die intern als separate Geräte behandelt werden. Der Hauptprozessor (Qualcomm IPQ8072A) hat die HW-Revision 272, und das Glasfaser-Modem (MaxLinear PRX321) die HW-Revision 273.

Zitat von hetti72

und die ist wiederum ein Joint Venture von Vonovia und der Telekom.

Laut der Gesellschafterliste im Handelsregister* gehören alle Geschäftsanteile der Vonovia SE. Die Telekom ist also nicht beteiligt.

Ich vermute mal, du hast die Info aus diesem Teltarif-Artikel. Ich weiß nicht, wie die darauf kommen, dass es ein Joint-Venture wäre. Laut Handelsregister war das nämlich seit der Gründung 2011 zu keinem Zeitpunkt der Fall.

Die normale Bauweise bei der Telekom ist, dass die Splitter im Hausanschluss verbaut werden. Meistens im Verhältnis 1:4, bei großen Gebäuden auch 1:32. In den Verteilern auf den Etagen (Sammelpunkte) wird nur die Steigleitung auf die Wohnungsleitung gespleißt.

Zitat von edding27

Weil auf einem der hier geposteten Diagramme sieht es ja so aus, als ob der Upload bereits komplett ausgelastet ist.

Die Fritzbox kann für den Upstream nur die zugeteilten Zeitschlitze sehen. Ob dann von den anderen ONTs tatsächlich Nutzdaten übertragen werden, sieht sie aber nicht.

Wahrscheinlich verhalten sich zumindest manche OLTs einfach so, dass sie die "überschüssige" Kapazität auf die ONTs verteilen. (Ansonsten wäre natürlich auch ein Anzeigefehler denkbar.)

Zitat von frank_m

Leider fehlt auch hier die eindeutige Spezifikation, was Transportprotokoll denn nun bedeutet. UDP? TCP? Paketgrößen?

Das Messverfahren der Breitbandmessung wird durch die Bundesnetzagentur hier konkretisiert. Gemessen werden demnach die TCP-Nutzdaten. Und die MTU ist ja immerhin Teil des Messprotokolls, sodass sich entsprechende Fehlkonfigurationen erkennen lassen.

Zitat von ConiKost

Also kann es folglich an der Adresse nur G.fast sein oder Ausbau FTTH durch Vodafone in Zukunft.

Es könnte auch einfach ein Datenfehler bei Vodafone sein.

Ich kenne hier eine Adresse wo laut Telekom der Ausbau untersagt wurde. Bei Vodafone wird Glasfaser aber als verfügbar angezeigt ("liegt schon vor Deiner Tür").

Generell scheint es so, dass Vodafone die Verfügbarkeit von Telekom-Glasfaser auf alle Homes-Passed-Adressen ausgeweitet hat. Bisher konnte man hier bei Vodafone erst bestellen, wenn schon der Hausanschluss liegt.

Ich denke ein kurzer Blick in die BEREC-Leitlinien zur Umsetzung der EU-Netzneutralitätsverordnung durch die nationalen Regulierer kann hier nicht schaden.

Im Punkt 140 geht es um die Transparenzangaben (Produktinformationsblatt), und da heißt es:

Zitat

Speeds should be specified on the basis of the transport layer protocol payload, and not based on a lower layer protocol.

Analog dazu in Punkt 166, wo es um das Messwerkzeug (hier Breitbandmessung) geht:

Zitat

Furthermore, speed should be calculated based on transport layer protocol payload.

Zitat von ConiKost

Ist mir nicht bekannt. Ich gehe davon aus, dass das erstmal nicht der Fall ist.

Falls du mal einen Moment Zeit hast, könntest du es ja nachprüfen mit einer Verfügbarkeitsabfrage an einer Telekom-FTTB-Adresse. Ich fände es auf jeden Fall interessant, ob da schon ein anderer Anbieter (1&1, o2, Vodafone) was im Programm hat (auch wenn ich ebenso vermute, dass es aktuell nicht der Fall ist).

Zitat von edding27

Andererseits frage ich mich, ob das nicht auch hätte in dem sagenumwobenen "Auskundsprotokoll" hätte stehen müssen von dem mir die Telekom erzählt hatte und wo angeblich "schon alles festgehalten ist" wie der Ausbau stattzufinden hat. Dort wird doch wohl auch stehen, welche Kastengröße benötigt wird.

Im Auskundungsprotokoll sollte die Anzahl der Wohneinheiten, Geschäftseinheiten, und Sonderleitungen stehen. Außerdem sind da die vorgesehenen Leitungswege mit Bildern beschrieben.

Wenn du keinen Zugang zum Protokoll hast, gibt es auch noch eine andere Möglichkeit, die Anzahl der Einheiten rauszufinden: Mache bei der Telekom eine Glasfaser-Verfügbarkeitsprüfung, und gehe bis zu dem Schritt wo gefragt wird, ob man Neu- oder Bestandskunde ist (die Adresse sollte mit "business-case-selection" enden). Dann im Browser den Quelltext anzeigen lassen, und nach "wE", "gE", und "sL" suchen.

Zitat von HubeBube

Ich kenne für MFH mit um 10 Wohnungen bei nachtäglicher Erschließung zumindest ein aktuelles Vorgehen beim Ausbau durch die Telekom: Es werden lediglich 2 bis 4 Fasern in die Immobilie eingebracht und die Verteilung findet in jedem Stockwerk durch optische Splitter statt.

Bist du sicher, dass die Splitter auf den einzelnen Stockwerken verbaut sind? Die übliche Bauweise bei der Telekom sind Splitter im Hausanschluss/Gebäudeverteiler (OneBox). Bei 10 WE würde ich erwarten, dass 3 Fasern aktiv genutzt werden, und jeweils mit einem 1:4-Splitter aufgeteilt werden. In den Etagenverteilern/Sammelpunkten werden dann nur die Fasern der Steigleitung auf die der Wohnungsleitungen gespleißt.

Zitat von Phino

Dies hier wäre eigentlich einer für MFH, aber auch nur ein kleines 14 Anschlüssen.

Es sind nur 8 Anschlüsse, denn die Plätze 9-14 sind hier ja nicht belegt. Das dürfte eine OneBox 4-8 WE von FiberHome sein.

Das auf dem Bild von edding27 sieht irgendwie eher nach der Onebox 3 WE aus. Aber das passt dann nicht so recht zu den 5 Wohnungen…