Leider doch, denn sie spiegeln die Nutzererfahrung wider.
In wie weit das? Der Test hat aktive Messungen gegen Server die die Nutzer in dem moment gar nicht brauchen, und passive Tests bei denen der Test nicht weiss was gerade passiert, ist die Uebertragungsrate gerade Sender-, Empfaenger-, oder Netzwerk-limitiert und wie bewertet der Nutzer das. Das weiss der Test nicht und da fragt er Test auch den Nutzer nicht nach...
Und das ist völlig valide, solange du nicht mithilfe dieser Einzelerfahrung einen Test mit 800 Millionen Datenpunkte diskreditieren willst.
Letzte Meldung, die Crowsourcing-Messung hat weder den Zweck die Peeringqualitaet von ISPs objektiv zu vergleichen, noch ist sie zu diesem Zweck geeignet. Daher sind diese 800 Millionen/Milliarden/... Datenpunkte fuer unsere Diskussion komplett irrelevant.
Die Anbieter können sich jederzeit um direktes Peering bemühen.
Das machen ja auch die meisten.
Eine Sichtweise. Eine andere Sichtweise ist, dass die Telekom hier gegen den Geist der EU Verordnung 2015/2120 verstoesst:
(4)
Ein Internetzugangsdienst bietet unabhängig von den vom Endnutzer verwendeten Netztechnologien und Endgeräten den Zugang zum Internet und somit grundsätzlich zu all seinen Abschlusspunkten. Es ist jedoch möglich, dass aus nicht von den Internetzugangsanbietern zu vertretenden Gründen bestimmte Abschlusspunkte des Internets nicht immer zugänglich sind. Daher sollte gelten, dass ein Anbieter seiner Verpflichtung im Zusammenhang mit der Bereitstellung eines Internetzugangsdienstes im Sinne dieser Verordnung nachgekommen ist, wenn der betreffende Dienst eine Anbindung an nahezu alle Abschlusspunkte des Internets bereitstellt. Daher sollten die Internetzugangsanbieter die Anbindung an keinen zugänglichen Abschlusspunkt des Internets beschränken.
(9)
Ziel eines angemessenen Verkehrsmanagements ist es, zu einer effizienten Nutzung der Netzressourcen und zur Optimierung der Gesamtübermittlungsqualität entsprechend den objektiv unterschiedlichen Anforderungen an die technische Qualität der Dienste bei speziellen Verkehrskategorien und somit den übermittelten Inhalten, Anwendungen und Diensten beizutragen. Von den Internetzugangsanbietern angewandte angemessene Verkehrsmanagementmaßnahmen sollten transparent, nichtdiskriminierend und verhältnismäßig sein, und sie sollten nicht auf kommerziellen Erwägungen beruhen. Die Anforderung, dass Verkehrsmanagementmaßnahmen nicht diskriminierend sein dürfen, schließt nicht aus, dass die Internetzugangsanbieter zur Optimierung der Gesamtübermittlungsqualität Verkehrsmanagementmaßnahmen anwenden, bei denen zwischen objektiv verschiedenen Verkehrskategorien unterschieden wird. Um die Gesamtqualität und das Nutzererlebnis zu optimieren, sollte jede derartige Differenzierung nur auf der Grundlage objektiv verschiedener Anforderungen an die technische Qualität der Dienste (beispielsweise in Bezug auf Verzögerung, Verzögerungsschwankung, Paketverlust und Bandbreite) bei bestimmten Verkehrskategorien, nicht aber auf Grundlage kommerzieller Erwägungen zulässig sein. Derartige differenzierende Maßnahmen sollten in einem angemessenen Verhältnis zum Zweck der Optimierung der Gesamtqualität stehen und gleichartigen Verkehr gleich behandeln. Derartige Maßnahmen sollten nicht länger als erforderlich beibehalten werden.
(15)
Drittens könnten Maßnahmen, die über derartige angemessene Verkehrsmanagementmaßnahmen hinausgehen, auch erforderlich sein, um eine drohende Netzüberlastung zu vermeiden, d. h. in Situationen, in denen sich die Überlastung abzeichnet, und zur Milderung der Auswirkungen einer Netzüberlastung, sofern diese Netzüberlastung nur zeitweilig oder unter außergewöhnlichen Umständen auftritt. Nach dem Grundsatz der Verhältnismäßigkeit ist es erforderlich, dass auf diese Ausnahme gestützte Verkehrsmanagementmaßnahmen gleichartige Verkehrskategorien gleich behandeln. Eine zeitweilige Überlastung sollte so verstanden werden, dass sie sich auf spezielle Situationen von kurzer Dauer bezieht, in denen ein plötzlicher Anstieg der Zahl der Nutzer über die Zahl der regelmäßigen Nutzer hinaus oder ein plötzlicher Anstieg der Nachfrage nach einzelnen Inhalten, Anwendungen oder Diensten die Übertragungskapazität einiger Netzkomponenten übersteigt und den Rest des Netzes schwerfälliger reagieren lässt. Eine zeitweilige Überlastung könnte insbesondere in Mobilnetzen auftreten, die variableren Bedingungen — wie etwa physische Störungen, geringere Versorgung in Gebäuden oder eine variable Zahl aktiver Nutzer mit Standortveränderungen — unterliegen. Es kann zwar vorhersehbar sein, dass eine derartige zeitweilige Überlastung gelegentlich an einigen Punkten des Netzes auftritt, und zwar so, dass sie nicht als außergewöhnlich betrachtet werden kann, ohne jedoch oft genug oder für so lange Zeiträume aufzutreten, dass eine Kapazitätserweiterung in wirtschaftlicher Hinsicht gerechtfertigt wäre. Eine außergewöhnliche Überlastung sollte so verstanden werden, dass sie sich — sowohl in Mobil- als auch in Festnetzen — auf unvorhersehbare und unvermeidbare Situationen der Überlastung bezieht. Mögliche Gründe für diese Situationen sind beispielsweise technisches Versagen — etwa ein Diensteausfall aufgrund beschädigter Kabel oder anderer beschädigter Infrastrukturkomponenten, unerwartete Änderungen bei der Verkehrslenkung oder eine erhebliche Zunahme des Netzverkehrs aufgrund von Notsituationen oder andere außerhalb der Kontrolle des Internetzugangsanbieters liegende Situationen. Diese Überlastungsprobleme dürften nicht sehr häufig auftreten, sind aber möglicherweise schwerwiegend und nicht zwangsläufig von kurzer Dauer. Die Erforderlichkeit, über die angemessenen Verkehrsmanagementmaßnahmen hinausgehende Verkehrsmanagementmaßnahmen anzuwenden, um den Auswirkungen einer zeitweiligen oder außergewöhnlichen Netzüberlastung vorzubeugen oder sie zu mildern, sollte den Betreibern von Internetzugangsdiensten nicht die Möglichkeit bieten, das allgemeine Verbot der Blockierung, Verlangsamung, Veränderung, Beschränkung, Störung, Schädigung oder Diskriminierung bestimmter Inhalte, Anwendungen oder Dienste oder bestimmter Kategorien derselben zu umgehen. Für wiederkehrende und länger dauernde Fälle von Netzüberlastungen, bei denen es sich weder um außergewöhnliche noch um zeitweilige Überlastungen handelt, sollte nicht auf diese Ausnahmen zurückgegriffen werden können, sondern sie sollten vielmehr im Wege einer Erweiterung der Netzkapazität angegangen werden.
Die Telekom verkauft ihren Kunden Internetzugang und steht damit in der Pflicht diesen nicht aus kommerziellem Interesse artifiziell einzuschraenken. Aber genau das tut die Telekom beim vorsaetzlichen Unterpeering prinzipiell. Die heisslaufenden Peerings (die die Telekom mit geringen Kosten erweitern koennte) dienen nur dem Zweck den Zugang zu den Endkunden der Telekom nochmals verkaufen zu koennen. Aber es ist eine Sache dem Geiste der Verordnung zu wider zu handeln und eine Andere dafuer belangt zu werden.
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.
Dann eruebrigt sich eine weitere Diskussion zwischen uns beiden zu diesem Thema, mehr als explizit klar machen warum der Test fuer unseren Zweck ungeeignet ist kann ich kaum leisten.
Da halte ich mich lieber an Messpunkte, die bei 736.000 Anschlüssen erhoben wurden. Im realen Leben.
Messpunkte, von denen Du erkennbar nicht weisst wie die zu interpretieren sind. Du laesst Dich da IMHO von einer grossen Zahl blenden ohne zu hinterfragen in wie weit diese Zahl repraesentativ ist.
Das geht ueber TATA in Newark, New Jersey...
Ach ja in der Vergangenheit war FDC Servers schlecht von der telekom aus erreichbar:
user@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.
, 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.
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).
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.
Nimmst du dann noch hinzu, dass die Telekom das schlechteste Internet aller Anbieter hat,
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.
Ansonsten ist die Telekom IMHO aus Endkundensicht ein zwar relativ teurer (teilweise der Regulierung geschuldet) aber kompetenter ISP. Und bei einigen Punkten wie Endgeraetewahlfreiheit ist die Telekom sogar ausnehmend kundenfreundlich.
Das heisst nicht, dass man der Telekom ihr vorsaetzliches Unterpeering entschuldigen muss, man kann IMHO die Telekom allein wegen dieses letztlich internet- und wettbewerbsfeindlichen Verhaltens als ISP meiden, aber man sollte nicht so tun als waere die Telekom generell ein schlechter ISP.
*) Die Telekom ist dabei relativ teuer, so zumindest die Aussagen verschiedener Mitarbeiter von anderen ISPs (auf 2 Kontinenten).
Was hat denn o2 und UGG mit Telekom zu tun?
Sorry, ich war verwirrt, weil ich kingpin42 s Vorschlag direkt mit meinem Link probieren wollte, da habe ich den Ueberblick verloren, dass es hier um UGG geht... Entschuldige bitte.
Trotzdem könnte Telefonica sich mal überlegen ob man Kunden aus Nürnberg immer über München routen muss auch wenn ein Ziel in Frankfurt ist.
O2 kauft L3-BSA bei der Telekom ein, da muss O2 klar sagen wohin der Traffic getunnelt werden soll, also zu welchem POP und dann geht aller Traffic darueber, weil die Telekom gar nicht auf die weiteren Header guckt...
D.h. die einzige Frage ist ob mann irgendwie zum O2 POP in Frankfurt oder Offenbach kommen kann...
EDIT: Das mit der Telekom ist offtopic, die spannendere Frage fuer diesen Thread ist, ob O2 und UGG inzwischen mehr Uebergaben haben, als die bekannte in Muenchen...
Wenn die Verbindung via PPPoE aufgebaut wird, könnt ihr mal versuchen, die Access Concentratoren zu „ersniffen“.
Unklar ob ich Dich richtig verstanden habe, aber der AC Name ist bei mit der vom lokalen Telekom BNG, erst ab da wird dann zu O2 getunnelt (basierend auf dem PPPoE Realm, wenn ich mich recht erinnere). Du meinst ich koennte da versuchen einfach mal einen AC name fuer, sagen wir Frankfurt zu synthetisieren? Muss ich mal ausprobieren
P.S.: Das ist Off-Topic hier im UGG Thread...
O2 hat nur etwa eine handvoll POP Standorte, neuerdings mit "Ueberlauf" in nahe Rechenzentren... das ist fast nie ganz ideal. Wohne zwischen Hamburg und Frankfurt, etwas naeher an Frankfurt, aber lande trotzdem zuverlaessig in/bei Hamburg.
Die neuen Preise sind immer noch guenstiger als die Telekom...
HTT ist wohl Heimstetten in Bayern, die Codes passen zu dieser List:
Das ist einer Gründe, warum ich AVM-Boxen komplett meide: Die selbstgebastelte Software weist zahlreiche Einschränkungen und Sicherheitslücken auf, die ein OpenWrt einfach nicht hat. Wenn man OpenWrt auf eine Fritzbox installiert, sind 100 % dieser auftretenden Seltsamkeiten verschwunden.
Da bin ich bei Dir (ich betreibe meine FB7520 als bridged modem unter OpenWrt, vor meinem OpenWrt basierten Hauptrouter und zwei OpenWrt APs).
Allerdings finde ich, dass AVM erfreulich langen Support liefert und bin deshalb nicht ungluecklich wenn der Rest meiner Familie bei Stock-AVM bleibt...
Die Antwort darauf ist einfach: Die Firewall und Shaper des Linux-Kernels sind bei AVM-Produkten nicht vorhanden. AVM setzt dort komplett auf selbstgebasteltes Zeug, um sich nicht an die GPL halten zu müssen.
Nein, AVM will das das so aussieht, aber die kochen auch nur mit Wasser und verwenden die qdiscs die der Kernel mitbringt. Bei FritzOS 8, schau einfach z.B. mit dem "strings" Befehl nach welche Strings sich in libfbqos.so.1.0.0 verstecken:
foslibs/high/fbqos/fbqos_queue.c
qdisc %s dev %s handle %x:%x parent %x:%x stab linklayer %s overhead %d tsize 100 mtu %u mpu %u tbf latency %ums burst %u mtu %u mpu %u rate %ukbit
tc -batch %s
/var/tc
%s-%s.setup
qdisc %s dev %s handle %x:%x parent %x:%x llq minq 1 maxq 255 default %u
class %s dev %s parent %x:%x classid %x:%x llq prio %u weight %u
qdisc %s dev %s handle %x:%x parent %x:%x tack
%s-%s.change
ingress
avm-ack-clfy
qdisc %s dev %s handle %x:%x parent %x:%x cake bandwidth %ukbit %s overhead %d %s %s %s
qdisc %s dev %s handle %x:%x parent %x:%x fq_codel
ethernet
qdisc %s dev %s handle %x:%x parent %x:%x tbf latency %ums burst %u mtu %u mpu %u rate %ukbit
qdisc %s dev %s handle %x:%x parent %x:%x prio bands %u priomap %s
7 0 1 2 3 4 5 6 7 7 7 7 7 7 7 7
set_default
qdisc %s dev %s handle %x:%x parent %x:%x nsstbl burst %u rate %ukbit accel_mode %u
qdisc %s dev %s handle %x:%x parent %x:%x nssprio bands %u accel_mode %u
qdisc %s dev %s handle %x: parent %x:%x nsspfifo limit 100
qdisc %s dev %s handle %x: parent %x:%x nssfq_codel limit 1000 target 15ms interval 100ms flows 1024 quantum %d %s
besteffort
dual-dsthost
noatm
%s-%s.switch
tc qdisc del dev %s rootMit Ausnahme der hardware beschleunigten QualCom NSS varianten kommen da die normalen cake, fq_codel, tbf Qdiscs des Kernels zum Einsatz.
Ja der Positionscode des ersten IP Hops im O2 Netz reportiert den Ort des POPs, wenn da muc steht ist Dein POP in Muenchen (bei mir steht da entweder ham fuer Hamburg oder ahr fuer Ahrensburg, d.h. der POP wird dynamisch zugewiesen (ich war auch schon mal in ber/Berlin gelandet)) .
EIn zu hoch eingestellter Traffic Shaper hat die selben Konsequenzen wie kein Traffic Shaper, d.h. das ist eigentlich keine Erklaerung fuer due angedeuteten Probleme.
Das ist doch ganz manierlich... ich nehme an Du haengst am O2 POP in Muenchen/muc?
Wähle aus, welche Kategorien Du erlaubst. Für jede Kategorie kannst Du über „Details anzeigen“ sehen, welche Cookies und Skripte konkret geladen werden, welche Empfänger beteiligt sind und wie lange gespeichert wird.
Weitere Informationen: Datenschutzerklärung · Impressum