Besser kann man die Überflüssigkeit seines Glasfaser-Produktes nicht demonstrieren.
Du hast bei Deinem Zitat den wesentlichen vorhergehenden Satz vergessen, das Zitat so aus dem Zusammenhang gerissen und eine falsche Schlussfolgerung gezogen.
Beiträge von Elemir
-
-
Das Teil ist ja eine echte Konkurrenz zu AVM.
Die Frage stellt sich, wie gut können sie mit den Eigenheiten des deutschen, europäischen Markt bei VDSL und Glasfaser umgehen (DS-Lite).
Das Gerät ist noch Recht neu, da kommt vielleicht noch das eine oder andere an Updates.
Aus meiner Erfahrung mit TP-Link heraus eher anders formuliert: kommen da noch Updates und wenn ja wie lange?
Denn von den technischen Daten her sieht das spannend aus, aber wenn es da in 2 Jahren eine Sicherheitslücke und keine Updates gibt ist es nicht schön.
-
Mein Kenntnisstand war, dass die Telekom den Plan nicht mehr benoetigte Vermittlungsstellen zu veraeussern im wesentlichen ad acta gelegt hat. Aber das mag inkorrekt sein. Ist aber auch egal, weil mein Wunsch zwar nicht unmoeglich zu erfuewllen ist, aber halt wie Du si schon schriebst weit "weg von der Realität"...
Das Angebot kam vor ca 3 Wochen neu, erst Gestern ist mir aufgefallen, dass es nicht mehr aktiv ist.
Dass nicht mehr zu wollen müsste dann sehr kurzfristig umgesetzt worden sein.
Entweder wird das marktabhängig gehandhabt wird oder es hätte dann doch gedauert, bis das "unten" ankam.
-
Das ist mir zu anekdotisch (ersetze "Die" durch "Meine"). Ein Blick auf die aktuellen Zahlen zeigt, wie sehr sich das digitale Leben bereits in den Mobilfunk verlagert hat. Andere Länder (siehe Baltikum) zeigen, wo wir ebenfalls in ein paar Jahren stehen werden.
Der Unterschied in der Bevölkerungsdichte (auch in den Städten) zwischen dem Baltikum und hier ist Dir aber schon bekannt?
Beliebig viel mehr Funkzellen aufbauen kann man auch nicht, die stören sich dann auch mehr gegenseitig.
-
Ich haette mir ja gewuenscht, dass man die PtP Struktur bis in to alten Vermittlungsstellen zieht, da muesste eigentlich genuegend PLatz sein, da stand ja mal die analoge Vermittlungstechnik... Aber vielleicht bin ich da zu optimistisch, und die gehoeren ja IMHO auch der Telekom und helfen daher anderen ausbauenden ISPs nur bedingt weiter.
Da bist Du nicht nur zu optimistisch, sondern auch weg von der Realität.
Leider ist das Angebot nicht mehr verfügbar, aber die Adresse ist ja angegeben:
https://www.immobilienscout24.de/expose/154566695#/
Da war nur noch ein Container in Garagengröße für die Telekom-Technik vorgegeben, der Rest stand für den Käufer für Wohnungsbau zur Verfügung.
-
Ich prognostiziere schon mal, dass sich ein Großteil der privaten Haushalte davor in den Mobilfunk flüchten wird.
Wenn das ein Großteil macht, dann wird mindestens in den Großstädten die Datenrate in den Mobilfunknetzen keinen mehr erfreuen.
-
Gibt es irgendwo eine Liste mit den zubuchbaren Optionen, wo ich die Dualstack Option finde? Wenn alles nach Plan läuft, wird bei uns nächste Woche die Faser eingeblasen und dann wohl alsbald der Tarif aktiviert und ich benötige auch DualStack, da mein RouterOS (OPNsense) kein DS-Lite unterstützt.
EDIT: habe nun das Dokument hier mit DualStack Hinweis gefunden: https://www.deutsche-giganetz.de/images/dgn/dow…ibung_MyNet.pdf
3,99 im Monat:
Allerdings erst in der aktuellen Preisliste. In unserem Vertrag war das nur als durch den Support zubuchbare Möglichkeit ohne Preis erwähnt.
-
Ich habe noch im Hinterkopf, dass Deutsche Giganetz als einer der zickigeren Provider auftritt, die das geltende TKG nicht wahrhaben wollen.
Ich habe zwar keine praktischen Erfahrungen damit, da wir am DGN-Anschluss den ONT der DGN nutzen, aber es ist sauber dokumentiert, was getan werden muss um ein eigenes ONT bzw. Router mit ONT zu nutzen und sie haben auch eine saubere Schnittstellenbescheibung veröffentlicht. Das ist schon so, seit ich mit dem Anschluss zu tun habe, also vor der BNetzA-Entscheidung.
Nur die Ersteinrichtung wollen sie mit ihrem ONT gemacht haben.
-
oder zwei, wenn es unterschiedliche Hausnummern sind.
Oder auch nicht, was dann später zu Verwirrung führt, wie ich es bei einem DSL-Anschluss schon erlebt habe. Das Haus hat mehrere Eingänge mit verschiedenen Hausnummern, aber nur einen HÜP. Und der HÜP liegt dann auch noch in einer anderen (Quer-)Straße als das Gebäude per Adresse/Hausnummer zugeordnet ist. Da kam Freude auf...
-
Bei mir jetzt auch kein Problem mehr. Zack, Download fertig.
Also genau der Effekt, den ich bei dem hier vor ein paar Tagen geposteten Test hatte. Erster Versuch läuft sich zu Tode und bricht mit Timeout ab, zweiter Versuch läuft dann problemlos durch.
Bei mir war das beides per IPv4 gleiche Quell- und gleiche Zieladresse, also nichts mit IPv4 und IPv6 unterschiedlich.
Was treibt die Telekom da?
-
sondern Mobilfunk nehmen. Der hat dann ein deutlich besseres Nutzungserlebnis.
Warum bist Du dann hier, wenn Dir das Mobilfunknutzungserlebnis ausreicht.
Vor allem, wenn das alle so machen ...
-
Hallo,
Moin,
Nun zu meiner eigentlichen Frage. Das Telekom-Modem würde ja aus dem Glasfasersignal ein Kupfersignal machen und das würde ich normalerweise mit meinem Router verbinden. Das Cloud Gateway Fiber hat einen SFP+ WAN port, kann ich mir das Modem nicht einfach sparen und direkt bei Glasfaser bleiben?
Prinzipiell ja
Meine Idee wäre es ein Single-Mode Opitical Modul von UI in den WAN-Port zu stecken und darein dann die Singlemode Glasfaser vom Hausanschluss.
Würde das funktionieren? Macht das Sinn?
Ein Modem kostet 40€ das Optical Modul nur 20€.
Das geht damit nicht. Die Telekom verbaut (wie fast alle Provider in Deutschland) GPON-Anschlüsse, da muss ein Modem noch etwas mehr leisten als nur eine reine Signalumwandlung von Glasfaser auf SFP, z.B. die Ver- und Entschlüsselung des Glasfasersignals. Du braucht da ein GPON-Modem in SFP+-Bauform.
Welche an Deiner UI laufen, können hier andere besser beantworten, da ich selber keine habe.
dann vom Cloud Gateway Fibre welches auch einen SFP+ Port hat ein SFP+ Kabel zu meinem Computer legen und in den dann eine entsprechende Netzwerkkarte installieren. Dann hätte ich Glasfaser bis zum Computer, mir gefällt der Gedanke irgendwie.
Macht das Sinn oder ist das nur Spielerei? Würde meine Latenzzeit dadurch am Computer geringer sein?
Durchgehend Glas hast Du so oder so nicht, da der SFP+-Port elektrisch ist. Ich denke nicht, dass das im Vergleich mit Gigabit-Ethernet spürbar etwas ausmacht.
-
Bei dem ganzen Geschimpfe auf das schlechte Telekom Peering, hat schonmal jemand drüber nachgedacht das die schlechte Erreichbarkeit von Cloudflare FREE tiers aus dem Telekom Netz, evtl. von Cloudflare bewusst beabsichtigt ist?
Dadurch gibt es einem guten Grund das Cloudflare Kunden von einem Free auf einen "Kostenpflichtigen" (keine ahnung wie das da heisst) Tier wechseln und Cloudflare hat mehr Geld in der Kasse.
Es betrifft ja nicht nur Cloudflare, sondern auch andere Provider, die keine solche Unterscheidung haben.
-
Wie der Name schon sagt: Cloudflare FREE-tier. Wenn der Cloudflare-Kunde schon nichts zahlen will, dann bekommt man eben auch nix!
Aber nur, wenn man Telekom-Kunde ist, für DGN-Kunden geht es gut.
-
Leider doch, denn sie spiegeln die Nutzererfahrung wider. Und nur die ist aus Kundensicht relevant, oder etwa nicht?
Jetzt kenne ich aber keinen dieser vielen Nutzer persönlich, um ihn zu fragen, ob das so stimmt oder nicht.
Aber ich "kenne" einen Nutzer mit gegenteiliger Erfahrung.
-
Und das ist völlig valide, solange du nicht mithilfe dieser Einzelerfahrung einen Test mit 800 Millionen Datenpunkte diskreditieren willst.
Wenn es nur eine Einzelerfahrung wäre. Und das lässt zumindest mich auch an diesem Test erheblich zweifeln.
-
Die Anbieter können sich jederzeit um direktes Peering bemühen.
Das machen ja auch die meisten.ja. Entgegen der üblichen Gepflogenheit das auf Gegenseitigkeit zu machen nur gegen Einwurf kleiner und großer Scheine.
Das auch noch mit völlig hirnverbrannter Begründung: die anderen würden viel mehr Daten zur Telekom schicken als die Telekom zu den anderen.
Dabei sind es Telekom-Kunden, die die Daten anfordern. Die großen Betreiber sollten dann einfach mal gar keine Daten mehr zur Telekom schicken, was dann wohl los wäre.
Außer, dass es Teilnehmer hier gibt, welche die Güte des Anschlusses an der Lautzeit zu dietpi.com festmachen.
Ich mache sie an meinen Beobachtungen fest. Und die sind negativ, wie in der Vergangenheit schon öfter gesehen und oben wieder gezeigt. Wenn ich nicht das bekomme, was ich aufrufe, dann ist das eine negative Erfahrung.
-
WTF, das ist ja interessant:
DGN alles gut:
wget -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits -4 --no-check-certificate
--2025-04-16 13:48:14-- https://lg-fra.fdcservers.net/1GBtest.zip
Auflösen des Hostnamens lg-fra.fdcservers.net (lg-fra.fdcservers.net)… 50.7.50.14
Verbindungsaufbau zu lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.14|:443 … verbunden.
Der Zertifikat-Eigentümer passt nicht zum Hostname »lg-fra.fdcservers.net«.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1073741824 (1,0G) [application/zip]
Wird in »/dev/null« gespeichert./dev/null 100%[===================>] 1,00G 339Mb/s in 26s
2025-04-16 13:48:40 (332 Mb/s) - »/dev/null« gespeichert [1073741824/1073741824]
Zeitgleich Telekom:
martin@pyrene[~]> wget -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits -4 --no-check-certificate
--2025-04-16 13:46:49-- https://lg-fra.fdcservers.net/1GBtest.zip
Auflösen des Hostnamens lg-fra.fdcservers.net (lg-fra.fdcservers.net)… 50.7.50.14
Verbindungsaufbau zu lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.14|:443 … verbunden.
WARNUNG: Keiner der alternativen Namen des Zertifikats stimmt mit dem angefragten Maschinennamen ‘lg-fra.fdcservers.net’ überein.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1073741824 (1,0G) [application/zip]
Wird in ‘/dev/null’ gespeichert./dev/null 15%[==> ] 158,50M 5,86Mb/s in 1m 44s
2025-04-16 13:48:34 (12,8 Mb/s) - Verbindung bei Byte 166199031 geschlossen. Erneuter Versuch.
^C
wget -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits -4 --no-check-certificate
--2025-04-16 13:48:59-- https://lg-fra.fdcservers.net/1GBtest.zip
Auflösen des Hostnamens lg-fra.fdcservers.net (lg-fra.fdcservers.net)… 50.7.50.14
Verbindungsaufbau zu lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.14|:443 … verbunden.
WARNUNG: Keiner der alternativen Namen des Zertifikats stimmt mit dem angefragten Maschinennamen ‘lg-fra.fdcservers.net’ überein.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1073741824 (1,0G) [application/zip]
Wird in ‘/dev/null’ gespeichert./dev/null 100%[===================>] 1,00G 627Mb/s in 14s
2025-04-16 13:49:13 (618 Mb/s) - ‘/dev/null’ gespeichert [1073741824/1073741824]
wget -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits -4 --no-check-certificate
--2025-04-16 13:50:37-- https://lg-fra.fdcservers.net/1GBtest.zip
Auflösen des Hostnamens lg-fra.fdcservers.net (lg-fra.fdcservers.net) … 50.7.50.14
Verbindungsaufbau zu lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.14|:443 … verbunden.
WARNUNG: Keiner der alternativen Namen des Zertifikats stimmt mit dem angefragten Maschinennamen ‘lg-fra.fdcservers.net’ überein.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: 1073741824 (1,0G) [application/zip]
Wird in ‘/dev/null’ gespeichert./dev/null 100%[===================>] 1,00G 640Mb/s in 14s
2025-04-16 13:50:51 (627 Mb/s) - ‘/dev/null’ gespeichert [1073741824/1073741824]
Der erste Versuch bei der Telekom bricht nach unendlich langsamer Verbindung ab (retry habe ich dann abgebrochen), die zwei Versuche danach mit "normaler" Geschwindigkeit.
Was passiert da? So wie der erste Versuch war es bei mir auch bei Linux Mint, aber Retry ebenso schlecht. Monitoren die da irgendwas neuerdings aktiv und machen spontanes Rerouten? Könnte ich nicht glauben, aber sieht extrem komisch aus.
-
Und dann gibt es Leute hier im Forum, die kommen mit einzelnen betroffenen Seiten. Und da reden wir von Webseiten. Die laden dann mit 0,5s statt 1,0s im Browser. Da musste ich nachmessen, sonst wäre mir der Unterschied nicht so sehr aufgefallen.
Das heißt natürlich nicht, dass es nicht andere Applikationen gibt, die davon nicht betroffen sein können. Aber da verweise ich auf meine Aussage bzgl. umlaut.
Wenn ich vom Telekom-Glasfaseranschluss aus das Linx-Mint-Paket vom Firefox nicht herunterladen kann, was dann beim Routen über ein VPN auf einen Proxy an einem DGN-Anschluss problemlos in Sekunden da ist und beim zurückstellen der Route wieder scheitert, dann fällt der Unterschied schon auf.
Allerdings scheint da inzwischen etwas passiert zu sein, den zu der URL habe ich inzwischen keine Probleme mehr. Da scheint also schon ein Netzmanagement einzugreifen, wenn es ganz extrem wird.
-
Telekom Glasfaser:
ping dietpi.com
PING dietpi.com (188.114.97.3): 56 data bytes
64 bytes from 188.114.97.3: seq=0 ttl=57 time=170.520 ms
64 bytes from 188.114.97.3: seq=1 ttl=57 time=171.970 ms
64 bytes from 188.114.97.3: seq=2 ttl=57 time=172.042 ms
64 bytes from 188.114.97.3: seq=3 ttl=57 time=172.055 ms
64 bytes from 188.114.97.3: seq=4 ttl=57 time=169.582 ms
64 bytes from 188.114.97.3: seq=5 ttl=57 time=171.922 ms
64 bytes from 188.114.97.3: seq=6 ttl=57 time=172.020 ms
^C
--- dietpi.com ping statistics ---
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max = 169.582/171.444/172.055 msping nordee.de
PING nordee.de (172.67.160.69): 56 data bytes
64 bytes from 172.67.160.69: seq=0 ttl=57 time=165.253 ms
64 bytes from 172.67.160.69: seq=1 ttl=57 time=164.491 ms
64 bytes from 172.67.160.69: seq=2 ttl=57 time=166.384 ms
64 bytes from 172.67.160.69: seq=3 ttl=57 time=164.468 ms
64 bytes from 172.67.160.69: seq=4 ttl=57 time=164.554 ms
^C
--- nordee.de ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 164.468/165.030/166.384 msDGN Glasfaser:
ping dietpi.com
PING dietpi.com (188.114.96.3) 56(84) bytes of data.
64 bytes from 188.114.96.3 (188.114.96.3): icmp_seq=1 ttl=57 time=7.06 ms
64 bytes from 188.114.96.3 (188.114.96.3): icmp_seq=2 ttl=57 time=5.84 ms
64 bytes from 188.114.96.3 (188.114.96.3): icmp_seq=3 ttl=57 time=5.67 ms
64 bytes from 188.114.96.3 (188.114.96.3): icmp_seq=4 ttl=57 time=6.38 ms
64 bytes from 188.114.96.3 (188.114.96.3): icmp_seq=5 ttl=57 time=6.07 ms
^C
--- dietpi.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 5.672/6.202/7.058/0.489 ms
ping nordee.de
PING nordee.de (172.67.160.69) 56(84) bytes of data.
64 bytes from 172.67.160.69 (172.67.160.69): icmp_seq=1 ttl=57 time=7.17 ms
64 bytes from 172.67.160.69 (172.67.160.69): icmp_seq=2 ttl=57 time=6.16 ms
64 bytes from 172.67.160.69 (172.67.160.69): icmp_seq=3 ttl=57 time=6.47 ms
64 bytes from 172.67.160.69 (172.67.160.69): icmp_seq=4 ttl=57 time=5.65 ms
^C
--- nordee.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 5.647/6.359/7.166/0.549 msTelekom DSL:
ping dietpi.com
PING dietpi.com (188.114.97.7) 56(84) bytes of data.
64 bytes from 188.114.97.7 (188.114.97.7): icmp_seq=1 ttl=57 time=178 ms
64 bytes from 188.114.97.7 (188.114.97.7): icmp_seq=2 ttl=57 time=177 ms
64 bytes from 188.114.97.7 (188.114.97.7): icmp_seq=3 ttl=57 time=177 ms
64 bytes from 188.114.97.7 (188.114.97.7): icmp_seq=4 ttl=57 time=177 ms
64 bytes from 188.114.97.7 (188.114.97.7): icmp_seq=5 ttl=57 time=177 ms
^C
--- dietpi.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 176.983/177.186/177.673/0.252 ms
ping nordee.de
PING nordee.de (104.21.9.158) 56(84) bytes of data.
64 bytes from 104.21.9.158 (104.21.9.158): icmp_seq=1 ttl=57 time=174 ms
64 bytes from 104.21.9.158 (104.21.9.158): icmp_seq=2 ttl=57 time=173 ms
64 bytes from 104.21.9.158 (104.21.9.158): icmp_seq=3 ttl=57 time=173 ms
64 bytes from 104.21.9.158 (104.21.9.158): icmp_seq=4 ttl=57 time=173 ms
^C
--- nordee.de ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 173.169/173.396/173.796/0.244 ms
