Gut, ich korrigiere auf schlechtester ISP auf ihrem eigenen Zugangsnetz. Es ging ja oben um Verfügbarkeit von Telekom VDSL. Zumindest so lange sie ihre Free Tier Ausweichtaktik fährt, ist sie an meiner Adresse der einzige ISP mit dieser seltsamen Symptomatik, bei der der ISP dem Kunden die Entscheidung vorenthält, welche Dienste wichtig sind und welche nicht.
Erfahrungen mit OpenInfra und Internetnord
-
-
C:\Users\phino> ping nordee.de
Ping wird ausgeführt für nordee.de [172.67.160.69] mit 32 Bytes Daten:
Antwort von 172.67.160.69: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.160.69: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.160.69: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.160.69: Bytes=32 Zeit=2ms TTL=59Ping-Statistik für 172.67.160.69:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 2ms, Maximum = 2ms, Mittelwert = 2msC:\Users\phino> ping dietpi.com
Ping wird ausgeführt für dietpi.com [172.67.193.183] mit 32 Bytes Daten:
Antwort von 172.67.193.183: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.193.183: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.193.183: Bytes=32 Zeit=2ms TTL=59
Antwort von 172.67.193.183: Bytes=32 Zeit=2ms TTL=59Ping-Statistik für 172.67.193.183:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 2ms, Maximum = 2ms, Mittelwert = 2msKann dann ja auch noch Test über Telekom (DSL/Gf) nachschieben.
-
Das ist IMHO zu dick aufgetragen. Ja, die Telekom hat eine letztlich Endkundenunfreundliche Peering Politik mit den anderen T1 ISPs, mit dem Ziel dass Inhalteanbieter Transit oder Peering bei der Telekom einkaufen*. Und bei Servern die ueber Fremd-Transit mit der Telekom fuehrt das oft zu Durchsatz- und Latenzproblemen waehrend der Spitzenzeit.
Das kann man natürlich kritisieren.
Allerdings solltest du aus Endkundensicht berücksichtigen, dass diese Fälle in den Crowdsourcing-Daten von umlaut einfließen. In den 800 Mio Samples von 736.000 Festnetzanschlüssen werden wohl ausreichend viele betroffene Verbindungen enthalten sein und das Erlebnis aus Nutzersicht bewerten. Es wäre ein gigantischer Zufall, wenn diese Verbindungen unterrepräsentiert wären.
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.
Am Ende entscheidet jeder ISP, wie er sein Netz betreibt. Dem Kunden ist vollkommen egal, was da hinter den Kulissen passiert. Bzw. er kann und muss das gar nicht wissen.
Und da gibt es aus Endkundensicht bei der Telekom nicht viel zu meckern.
Da haben wir bei jedem ISP bereits hier im Forum Mängel dokumentiert. Überlastete PoPs, überlastetes Peering, überlastetes CG-NAT, einzelne BNGs für ganz Deutschland mit entsprechenden Laufzeiten, hohe Latenzen, bevor überhaupt der erste L3-Hop erreicht wird, etc.
Zum Glück habe ich den anderen Teilnehmer nun wieder blockiert, dann habe ich auch mehr Zeit und Muße für sinnvolle Diskussionen.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Kann dann ja auch noch Test über Telekom (DSL/Gf) nachschieben.
Danke, also die 94 ms waren Bestwerte über Telekom Glasfaser, VDSL macht dann 97 und 5G 103 ms. Ich war ja so fair, der Telekom die meisten Chancen zu bieten, nicht weit abgeschlagen den letzten Platz zu holen.
-
fiberone.de Anschluss
Codenordee.de PING 172.67.160.69 (172.67.160.69) with 64 bytes of data: 64 bytes from 172.67.160.69 ttl=59 time=1.193 ms 64 bytes from 172.67.160.69 ttl=59 time=1.124 ms 64 bytes from 172.67.160.69 ttl=59 time=1.121 ms 64 bytes from 172.67.160.69 ttl=59 time=1.179 msCodedietpie.com PING 172.67.193.183 (172.67.193.183) with 64 bytes of data: 64 bytes from 172.67.193.183 ttl=59 time=1.319 ms 64 bytes from 172.67.193.183 ttl=59 time=1.194 ms 64 bytes from 172.67.193.183 ttl=59 time=1.199 ms 64 bytes from 172.67.193.183 ttl=59 time=1.168 ms -
Allerdings solltest du aus Endkundensicht berücksichtigen, dass diese Fälle in den Crowdsourcing-Daten von umlaut einfließen. In den 800 Mio Samples von 736.000 Festnetzanschlüssen werden wohl ausreichend viele betroffene Verbindungen enthalten sein und das Erlebnis aus Nutzersicht bewerten. Es wäre ein gigantischer Zufall, wenn diese Verbindungen unterrepräsentiert wären.
Lies bitte meine Kritik, der Crowdsourcing Test ist "speziell"... bzw. wenn man sich die Beschreibung durchliest sollte klar werden, dass dieser Test fuer unsere Diskussion schlicht wenig geeignet ist.
Hier eine Frage weil Du konsistent als Verteidiger des Connect-Tests auffaellst, hast Du internes Wissen ueber den Test der Dich dazu bringt dessen Qualitaet anders zu bewerten als ich (ich will Dich nicht draengen Interna auszuplaudern, ein einfaches "ja" oder "nein" reicht
)?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 Problem hat auch andere Auspraegungen, wie Durchsatzraten zu ausgewaehlten Servern die in der Spitzenzeit ueber die Telekom auf 2-3-stellige Kbps Werte einbrechen, nicht jedoch ueber andere ASe. Die Ping-Tests hier haben allerdings den Vorteil, dass sie sehr leicht zu ueberpruefen sind.
Am Ende entscheidet jeder ISP, wie er sein Netz betreibt. Dem Kunden ist vollkommen egal, was da hinter den Kulissen passiert. Bzw. er kann und muss das gar nicht wissen.
Und da gibt es aus Endkundensicht bei der Telekom nicht viel zu meckern.
Ausser halt des vorsaetzlichen Unterpeerings... allerdings muss einem das erst mal auffallen, nicht alle Nutzer sind gleich davon betroffen und nur wenige Nutzer duerften in der Lage sein das Problem korrekt zu diagnostizieren...
Da haben wir bei jedem ISP bereits hier im Forum Mängel dokumentiert. Überlastete PoPs, überlastetes Peering, überlastetes CG-NAT, einzelne BNGs für ganz Deutschland mit entsprechenden Laufzeiten, hohe Latenzen, bevor überhaupt der erste L3-Hop erreicht wird, etc.
Das ist alles wahr, allerdings handelt es sich da oft um transiente Probleme/Engpaesse. Das ist hier nicht der Kritikpunkt, bzw. da habe ich volles Verstaendnis, dass ISPs Zeit brauchen um ihr Netz anzupassen, wenn sich die Last aendert. Das Problem beim vorsaetzlichen Unterpeering der Telekom ist, dass es ein gewollter Dauerzustand ist.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Wenn man bedenkt das der 2 Gigabit Tarif bei der Telekom knapp 140€ im Monat kostet, dann ist der 8 Gigabit Tarif sehr günstig. Ich habe in Deutschland noch keinen Glasfaser-Provider gesehen der so günstig ist (da können sich fast alle anderen Glasfaser-Provider eine Scheibe abschneiden).
Ja ;=) nur wer braucht die 8000?! darauf zählen die doch dass das keiner nutzen wird
-
Na dann will ich mal
https://www.lwlcom.net/Stark!
-
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 -
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
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.
-
dietpie.com wird bei mir zu Amazon/AWSglobal aufgeloest... (aendert an der RTT nicht viel, ueber AWS oder Cloudflare bei 9-10ms, und das ist auch die Latenz zum ersten ISP-Hop).
-
Ok, die 170 ms liegen aber ja schon über den 150, die die Bundesnetzagentur als Latenz für die Mindestversorgung angeordnet hat. Insofern ist da der Spaß für mich auch vorbei, da stellt man sich nur noch als Narr dar, wenn man die Telekom hier noch verteidigen möchte. Mit so einem Ergebnis muss ich mich mit keiner einzigen Testadresse zufrieden geben.
Ich kann an der Stelle nur hoffen, dass 77 nicht auf das Geburtsjahr des Users hindeutet. Bis dato hatte ich gedacht, das er knapp doppelt so alt ist wie ich und daher eine gewisse Reife an den Tag legen sollte.
pufferueberlauf dietpi.com ist die Referenz, dietpie ist ein Typo. Daher vielleicht lieber nordee.de nehmen.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
, die 170 ms liegen aber ja schon über den 150, die die Bundesnetzagentur als Latenz für die Mindestversorgung angeordnet hat.
Jain, die BNetzA definiert die Latenz da als OWD, d.h. die RTT darf bis zu 300ms werden... und die BNetzA Latenz gilt nur gegen die breitbandmessung.de Messserver...
pufferueberlauf dietpi.com ist die Referenz, dietpie ist ein Typo. Daher vielleicht lieber nordee.de nehmen.
Ah, danke, mein Fehler...
Insofern ist da der Spaß für mich auch vorbei, da stellt man sich nur noch als Narr dar, wenn man die Telekom hier noch verteidigen möchte. Mit so einem Ergebnis muss ich mich mit keiner einzigen Testadresse zufrieden geben.
Jain, wenn der Server einfach weit entfernt ist, sind solche Latenzen un vermeidbar (z.B. VC mit der Westkueste der USA) bei einem CDN hingegen wird das abenteuerlich. Theoretisch gehoeren da natuerlich immer zwei dazu, d.h. die Umleitung ueber die USA mag auch von Cloudflare kommen, aber bestimmt nicht nur aus Jux und Dollerei, sondern weil die kuerzeren Pfade entweder bereits ausgelastet sind, oder aber zu teuer sind.
-
Ach ja in der Vergangenheit war FDC Servers schlecht von der telekom aus erreichbar:
Code
Alles anzeigenuser@123-1234567 / % wget -O /dev/null https://lg-fra.fdcservers.net/1GBtest.zip --report-speed=bits -4 --no-check-certificate --2025-04-16 13:09:33-- https://lg-fra.fdcservers.net/1GBtest.zip Resolving lg-fra.fdcservers.net (lg-fra.fdcservers.net)... 50.7.50.14 Connecting to lg-fra.fdcservers.net (lg-fra.fdcservers.net)|50.7.50.14|:443... connected. WARNING: no certificate subject alternative name matches requested host name ‘lg-fra.fdcservers.net’. HTTP request sent, awaiting response... 200 OK Length: 1073741824 (1,0G) [application/zip] Saving to: ‘/dev/null’ /dev/null 100%[======================================================================================================================>] 1,00G 70,0Mb/s in 1m 45s 2025-04-16 13:11:18 (81,9 Mb/s) - ‘/dev/null’ saved [1073741824/1073741824]81.9 Mb/s ist voll OK weil das Netz nicht inaktiv war...
Der Pfad war hier allerdings ueber TATA, nicht Cogent.
FDCServcers ist zwar nicht mehr Single-Homed bei Cogent, hat aber AS3320/DTAG weder als Provider noch als Peer.
-
Mit Telekom Glasfaser von Berlin aus.
Es geht direkt von Berlin nach New York und zwar Firmenintern.
Das sind doch garantiert T-Mobile USA Knoten die da genutzt werden.
Da spart man auch noch Geld seitens Telekom, weil ja die "bösen" von Cloudflare sich nicht in das teure Peering einkaufen wollen.Code
Alles anzeigenTarget Name: dietpi.com IP: 172.67.193.183 Date/Time: 16.04.2025 13:28:16 - 16.04.2025 13:38:16 Hop Sent PL% Min Max Avg Host Name / [IP] 1 16 0 0,38 0,66 0,50 fritz.box [192.168.178.1] 2 17 0 1,72 2,33 2,00 p3e9bf07f.dip0.t-ipconnect.de [62.155.240.127] 3 16 0 93,50 94,13 93,92 nyc-sb6-i.NYC.US.NET.DTAG.DE [62.154.5.202] 4 16 0 93,15 93,79 93,45 nyc-sb6-i.NYC.US.NET.DTAG.DE [62.154.5.202] 5 16 0 87,99 104,25 89,33 80.156.160.213 [80.156.160.213] 6 16 0 95,24 99,53 96,21 if-ae-0-2.tcore3.njy-newark.as6453.net [216.6.90.14] 7 16 0 98,53 108,68 100,92 66.198.70.2 [66.198.70.2] 8 16 6 95,16 108,89 98,96 162.158.61.125 [162.158.61.125] 9 16 0 96,10 96,62 96,34 dietpi.com [172.67.193.183] -
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
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.
-
Das geht ueber TATA in Newark, New Jersey...
-
Jain, die BNetzA definiert die Latenz da als OWD, d.h. die RTT darf bis zu 300ms werden...
Aua, ok, danke...
und die BNetzA Latenz gilt nur gegen die breitbandmessung.de Messserver..
Das ist mir klar, ich meinte das nur als Größenordnung für die Bemessung. Aber bei 300 ms wird man dem Begriff der Grundversorgung dann auch wirklich gerecht...
Das sind doch garantiert T-Mobile USA Knoten die da genutzt werden.
Dem ist so, dürfen sie ja so machen, nur nicht damit rechnen, dass das allen Nutzern so gefällt.
Mit der Testdatei ist der Vogel dann aber abgeschossen, wenn ich sowas als Referenz nehme, ist es doch deutlich genug.
Edit: Das komische Phänomen tritt bei meinem Telekom-Testanschluss aber nicht auf, der Download erreicht hier die Höchstgeschwindigkeit von knapp 70 Mbit/s, die der Tunnel erlaubt. Ist halt nur ein 150er Tarif.
-
Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
-
Das Problem beim vorsaetzlichen Unterpeering der Telekom ist, dass es ein gewollter Dauerzustand ist.
Die Anbieter können sich jederzeit um direktes Peering bemühen.
Das machen ja auch die meisten.Lies bitte meine Kritik, der Crowdsourcing Test ist "speziell"... bzw. wenn man sich die Beschreibung durchliest sollte klar werden, dass dieser Test fuer unsere Diskussion schlicht wenig geeignet ist.
Sehe ich nicht so. Unter Interna habe ich keine.
Die Kritik konnte ich beim letzten Mal bereits nicht nachvollziehen und da kommt dann der Punkt, wo ich das zu den Akten lege, da wir uns im Kreis drehen. Auch heute gibt es für mich keinerlei Erkenntnisgewinn. Außer, dass es Teilnehmer hier gibt, welche die Güte des Anschlusses an der Lautzeit zu dietpi.com festmachen.Da halte ich mich lieber an Messpunkte, die bei 736.000 Anschlüssen erhoben wurden. Im realen Leben.
-
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.
