Beiträge von pufferueberlauf

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.

Zitat von DLMttH

, 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...

Zitat von DLMttH

pufferueberlauf dietpi.com ist die Referenz, dietpie ist ein Typo. Daher vielleicht lieber nordee.de nehmen.

Ah, danke, mein Fehler...

Zitat von DLMttH

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).

Zitat von mbo77

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 )?

Zitat von mbo77

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.

Zitat von mbo77

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...

Zitat von mbo77

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.

Zitat von DLMttH

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).

Zitat von 5G/FTTH-Tester

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.

Zitat von 5G/FTTH-Tester

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...

Zitat von kingpin42

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:

https://service.unece.org/trade/locode/de.htm

Zitat von wandler

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...

Zitat von wandler

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 root

Mit 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?

Ja, das Fehlerbild ist ziemlich unklar, leider. Und die Fritzboxen sind auch leider etwas zu stark verrammelt (so dass man kaum Informationen vom Linuxkernel bekommen kann, ob/wie die Shaper konfiguriert sind).

Ich vermute der Umstand dass nur wenige Betroffen sind ist ein zweischneidiges Schwert, gut, dass das Problem selten auftritt, aber IMHO auch der Grund warum das ganze wohl niedrige Prioritaet hat, oder?

Ich wuenschte AVM wuerde mich mal kontaktieren... die einzige Auswirkung eines zu niedrig gestellten Shapers sollte es sein, dass der Durchsatz insgesamt niedriger ist, die reportierten Probleme sind alle orthogonal zu einen kompetent aufgesetzten Traffic-Shaper.

Der Artikel ist allerdings etwas duenn was Details angeht, daher ist es schwer irgend etwas genaues daraus zu lesen.

Oh, die Ranger-Leute haben kein gesteigertes Interesse an FTTH Ausbau, die werden angeheuert um hier und heute Kunden zu gewinnen, meistens halt per VDSL...

Das die Vonovia da ein Hausrecht hat steht ausser Zweifel, was ich anzweifle ist, dass die das primaer im Sinne ihrer Mieter einsetzt...

Mal eine Frage an die O2@UGG Nutzer: Wie sieht den die Latenz zum ersten O2-Hop inzwischen aus? Abhaengig von der Entfernung zum Pop-Standort.

# Unter https://github.com/fujiapple852/trippy/releases zur aktuellen Release navigieren und unter Assets das passende Archiv fuer das eigene Endsystem (Windows, Macos, Linux) runterladen und lokal entpacken.
# Unter Windows CMD als Administrator starten, ins Verzeichnis mit der Datei trip.exe wechseln und folgendes aufrufen, die Firewall muss eventuell fuer Trippy geoeffnet werden.
trip --mode pretty --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -4 one.one.one.one --tui-custom-columns holsravbwdt --icmp -C 100
# jeweils nach ca. 100 Messungen Trippy einfrieren (mit CTRL-f) und deinen Screenshot machen und posten

Hier ein Beispiel von meinen VDSL2 Link ( Vorleister Telekom, ~250 Km vom POP Standort in Ahrensburg entfernt)

┌─────┬───────────────┬──────────────────────────────────────────────────────┬───────┬─────┬──────┬──────┬──────┬──────┬──────┬────────┐
│ Hop ┆ IPs           ┆ Addrs                                                ┆ Loss% ┆ Snt ┆ Recv ┆ Last ┆ Avg  ┆ Best ┆ Wrst ┆ StdDev │
╞═════╪═══════════════╪══════════════════════════════════════════════════════╪═══════╪═════╪══════╪══════╪══════╪══════╪══════╪════════╡
│ 1   ┆ 192.168.42.1  ┆ 192.168.42.1                                         ┆ 0.0   ┆ 100 ┆ 100  ┆ 0.6  ┆ 0.7  ┆ 0.4  ┆ 1.1  ┆ 0.1    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 2   ┆ 62.52.192.240 ┆ loopback1.0001.acln.01.ahr.de.net.telefonica.de      ┆ 0.0   ┆ 100 ┆ 100  ┆ 11.3 ┆ 11.1 ┆ 9.9  ┆ 13.7 ┆ 0.7    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 3   ┆ 62.53.11.234  ┆ bundle-ether4.0002.cord.01.ahr.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 11.1 ┆ 10.9 ┆ 9.7  ┆ 12.4 ┆ 0.5    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 4   ┆ 62.53.3.36    ┆ bundle-ether21.0003.corx.01.ham.de.net.telefonica.de ┆ 0.0   ┆ 100 ┆ 100  ┆ 12.3 ┆ 12.0 ┆ 10.2 ┆ 19.6 ┆ 1.2    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 5   ┆ 62.53.14.29   ┆ bundle-ether2.0001.dbrx.06.ham.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 12.1 ┆ 11.7 ┆ 10.7 ┆ 13.0 ┆ 0.5    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 6   ┆ 62.53.2.91    ┆ bundle-ether1.0001.prrx.06.ham.de.net.telefonica.de  ┆ 0.0   ┆ 100 ┆ 100  ┆ 12.0 ┆ 11.9 ┆ 10.8 ┆ 14.0 ┆ 0.6    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 7   ┆ 193.42.155.58 ┆ as13335.hamburg.megaport.com                         ┆ 0.0   ┆ 100 ┆ 100  ┆ 27.8 ┆ 15.9 ┆ 10.5 ┆ 40.4 ┆ 7.7    │
├╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌┼╌╌╌╌╌╌╌┼╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌┼╌╌╌╌╌╌╌╌┤
│ 8   ┆ 1.0.0.1       ┆ one.one.one.one                                      ┆ 0.0   ┆ 100 ┆ 100  ┆ 11.6 ┆ 11.4 ┆ 10.4 ┆ 13.2 ┆ 0.5    │
└─────┴───────────────┴──────────────────────────────────────────────────────┴───────┴─────┴──────┴──────┴──────┴──────┴──────┴────────┘

Die ~10 Millisekunden sind nicht grossartig, aber ob der Entfernung und vermuteten Anzahl an L2 Hops OK. Bei Anschluessen ueber die UGG waren diese Werte frueher oft eher bei 20-30 Millisekunden. Ist das immer noch so, oder ist das Problem entschaerft worden?