Beiträge von mbo77

Nein, das ist ziemlich klar. Dazu kannst du dir gerne mal ein Protokoll der Messung ansehen. Das zeigt an, wo ein Verstoß vorliegt.

Für den Kunden ist die Technik dahinter völlig belanglos. Und wenn sich 1&1 entscheidet, die Pakete per Brieftaube zu transportieren und sie dabei Latenz und Bandbreite einhalten, ist alles prima. Ich meine, die BNetzA sieht 150 ms als akzeptabel an.

Alles andere Nebelkerzen helfen auch nicht weiter: Des Messwerkzeug ist definiert. Meinst du das etwas ernst, dass die die Messkampagne mit 5 Bytes Payload durchführen?

Transparenzverordnung, Messwerkzeug und Auswertung sind vorgegeben. Alles andere ist für den Kunden irrelevant.

Das Beste ist: 1&1 hat hier völlig ohne Not einen Bock geschossen. Wenn sich ein paar Leute über die Messkampagne beschweren, werden sie recht schnell selbst ihren Fehler finden.

Ein Blick in die Vorgaben des verpflichtenden Produktinformationsblattes bringt Klarheit:

"(Maximal/Normalerweise/Mininmal) zur Verfügung stehend"

Damit reißt 1&1 diese Vorgabe und die Auswertung der Messkampagne wird die Verstöße visualisieren.

Ich würde eine Messkampagne bei der BNetzA machen. Dann hast du Gewissheit.

Da hat sich 1&1 ohne Not ein schönes Ei gelegt.

Du meinst das hier, oder?

https://content.1und1.de/pib/BB_Glasfaser_300_MVL_20240701.pdf

Die geben tatsächlich 150 Mbps als Minimum an.

Rein praktisch kenne ich keinen SFP, der auch nur 2,5G unterstützt.

Solange sie die App nicht verfummeln, ist mir das egal. Habe die Seite mobil schon Ewigkeiten nicht mehr aufgerufen.

Zitat von Kaj Kandler

Wie soll ich mich verhalten bzgl. meines noch bis Aug 2025 laufenden Vertrages?

Ab dem Zeitpunkt ist der Vertrag monatlich kündbar. Das wird dich also kaum tangieren.

Oh, das scheint mir auch neu.. Oder war das schon immer so?

Zitat von XTreMe

Ich verstehe, dass ein Parallelbetrieb möglich ist, aber wenn neue Gebiete erschlossen werden und XGS-PON eingesetzt wird, macht es keinen Sinn einen zweiten "Hardwarezweig" für PON und XGS-PON zu betreiben, sondern nur XGS-PON einzusetzen.

Daher wäre es interessant zu wissen, wo die GF+ bereits XGS-PON ausbaut, mir sind nur Testgebiete direkt von der Telekom bekannt.

Die OLTs beherrschen Mischbetrieb. Ob dieser in einem Neubaugebiet sinnvoll ist, kann vielleicht kingpin42 beantworten. Er hat da praktische Erfahrung für einen anderen Provider.

Du hast auf speedmeter.de verlinkt.

Also mit den Bauarbeiten hat es nichts zu tun. Jedes Netz kann parallel GPON, XGS-PON und Folgestandards parallel bedienen.

Ich sehe gerade, dass ich gestern einen Ping in der Konsole vergessen habe:

93714 packets transmitted, 93635 packets received, 0% packet loss
round-trip min/avg/max = 49.233/52.462/1199.327 ms

Dauertest über 26 Stunden. Das sieht recht stabil und verlässlich aus.

Zitat von Edding

Die Übergabe könnte in Barcelona sein und je nach dem wo das Ferienhaus ist die Latenz erklären.
Bei GPON fahren einige auch einer ehe konservative config was Latenz angeht um den Overhead niedrig zu halten.

Distanz kann kaum eine Rolle spielen. Da dürfte die Latenz kaum bei 1 ms liegen.

Der Großteil wird wohl eher an der konkreten Systemkonfiguration liegen.

Und danke für das native Beispiel.

Nein, die Folgekosten sind bestimmt nicht höher.

Es ist erstmal wie immer in der Industrie. Es braucht zwei bis drei Iterationen, bis man sich auf einen Standard einigt. Denn es gibt ja keinerlei technischen Hürden, lediglich prozessuale.

Was du meinst ist eine Gf-Dose. Ein ONT ist immer eine aktive Komponente.

Darüber hinaus rate ich davon ab, wenn es dir nur um das Basteln geht. Das System ist recht groß dimensioniert und braucht entsprechend viel Strom.

Ob du bei deinem Provider ein GPON-SFP provisioniert bekommst, hängt von weiteren Faktoren ab. Vielleicht gibt es hier im Forum jemanden, der Erfahrung mit dem konkreten Provider hat.

pfSense/OPNsense hat gerade bei PPPoE-Verbindungen Nachteile.

Du wärst dann mit OpenWRT als Distribution besser aufgehoben.

Um Strom und Geld zu sparen, wäre stattdessen ein https://wiki.banana-pi.org/Banana_Pi_BPI-R4 besser geeignet. Oder der Vorgänger R3.

Aber da würde ich lieber den GPON-Medienwandler vorschalten.

Hier ein bisschen Erfahrungsbericht aus Katalonien in Spanien.

Die Ferienwohnung hat einen Anschluss über Digi Fibra, einer rumänischen Firma, die mittlerweile auch Anschlüsse in Spanien anbietet. Sollte dieser Anschluss bereits über das eigene Netz erfolgen, liegen die Preise bei 15/20/25 €/Monat bei 0,5/1/10 Gbps symmetrischer Bandbreite.

Mieten sie sich nur in bestehende Netze ein, gibt es Angebote mit 0,3 oder 1 Gbps symmetrisch für 25/30 €/Monat.

Die Vor-Ort-Installation ist meiner Erfahrung nach recht typisch (was aber weniger am ISP liegt). Irgendwie alles zusammengeworfen und das Gf-Kabel scheint zumindest relativ robust zu sein. Auf die Idee, den ONT an die Wand zu nageln, ist wohl noch keiner gekommen.

Der konkrete Anschluss bietet 0,3 Gbps an.

Noch ein bisschen was zu der Erfahrung.

Ich habe meinen Urlaubsrouter angeschlossen und da ich nicht mit PPPoE oder DHCP-Leases herumfummeln wollte, ist der per Doppel-NAT an einem LAN-Port des Provider-Routers angeschlossen.

Meine Speedtests zeigen, dass die Performance auch in etwa erreicht wird. Da ich aber via WiFi arbeite, messe ich dem nicht zu viel Bedeutung bei.

Interessant ist noch das Routing. Ich bin dazu auf der bash des OpenWRT angemeldet:

traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 46 byte packets
1  192.168.1.1 (192.168.1.1)  0.791 ms  0.710 ms  0.658 ms
2  10.0.45.203 (10.0.45.203)  13.551 ms  13.911 ms  13.683 ms
3  172.16.1.1 (172.16.1.1)  13.938 ms  13.853 ms  13.603 ms
4  10.220.96.6 (10.220.96.6)  14.095 ms  10.220.98.26 (10.220.98.26)  13.672 ms  10.220.96.6 (10.220.96.6)  18.651 ms
5  86-120-71-50.rdsnet.ro (86.120.71.50)  14.020 ms  13.812 ms  81-196-118-216.rdsnet.ro (81.196.118.216)  13.577 ms
6  cloudflare.baja.espanix.net (193.149.1.56)  23.163 ms  14.813 ms  188.114.108.68 (188.114.108.68)  14.534 ms
7  188.114.108.67 (188.114.108.67)  14.822 ms  188.114.108.61 (188.114.108.61)  14.509 ms  118.114.108.73 (118.114.108.73)  14.853 ms
8  one.one.one.one (1.1.1.1)  14.572 ms  14.444 ms  14.645 ms

Der Provider nutzt statt der CG-NAT-Range einfach die private Range. Ich habe noch nicht gesehen, ob man den Router überhaupt modifizieren kann. Aber Endgerätefreiheit gibt es de facto in Spanien nicht. Ganz langsam regt sich diesbezüglich Widerstand. Daher können sie auch einfach ein privates Netz zur Verbindung nehmen, wenn sie das lokale Netz ohnehin vorgeben.
Aber wenigstens gibt es eine passive Gf-Dose, die für den Kunden nutzbar ist.

Die Laufzeiten zum ersten Hop im Layer 3 ist erstaunlich hoch. Dahinter sind die Laufzeiten wirklich gut. Theoretisch soll der Hop 5 der IP nach in Rumänien stehen, aber das kann ich mir nicht vorstellen, denn das Paket geht danach zurück nach Spanien. Das geht von den Laufzeiten schon nicht auf.

Ich habe verschieden Ziele getestet und immer Laufzeiten in dieser Größenordnung vorgefunden, solange ich in Spanien bleibe. Vermutlich ist viel davon in oder in der Nähe von Barcelona gehostet.

Die Wireguard-Verbindung in mein Heimnetz funktioniert gut. Die Latenz liegt bei 60 ms, aber die Bandbreite (100/40 eines VDSL-Anschlusses) wird voll erreicht.

Ergänzung: Und hier die Erklärung, weshalb im Bestand ebenfalls zügig eine hohe Durchdringung erreicht wurde.

Ich sehe keine Anzeichen, dass es an deinem System liegt.

Aber ein live gebootetes Linux-Image wäre noch ein Test, den ich sicherheitshalber machen würde.

Da man nirgendwo eine eigene Leitung zu den Servern hat, kann es alles mögliche sein.

Wenn der Techniker schon selbst den PoP ins Spiel bringt, wäre das eine mögliche Komponente.

Hast du den Speedtest mal gegen verschiedene Ziele getestet? Und sicherheitshalber mit der nativen App messen.

Schon krass. Die Telekom nimmt dafür 70 €. Bei 500 Mbps Upload.

Es ist nicht unwahrscheinlich, dass 1&1 in der nächsten Tarifstruktur der Telekom folgt. Und die sind ja eigentlich immer günstiger als die Telekom.

Ich glaube, Marcel1 war da dran. Der ist aber seit einem Jahr hier offline.