Oh, das sollte keine Kritik sein, mir war das nur zu aufwendig... und wenn mann das scripten will ist das ueber die Kommandozeile IMHO einfacher.
Fun Fact: IONOS hat die Telekom als Transit-Provider, kein wunder dass die ueber die DTAG gut erreichbar sind.
Strato, als Ionos Tochter?Marke routet komplett ueber IONOS:
Mmmh der trace sieht auch so aus als ginge der Vorwaertsweg ueber Amsterdam... wenn Du nicht direkt an der niederlaendischen Grenze wohnst erscheint mir das auf den ersten Blick, sagen wir, sub-optimal... allerdings ist fuer den Transfer die andere Richtung wichtiger, und ueber die wissen wir leider sehr wenig...
--report-speed=bits
2025-01-11 15:55:01 (42.7 Mb/s) - ‘/dev/null’ saved [1830207094/1830207094]
Das sind leider keine 37 MegaByte/Sekunde, sondern nur MegaBit/Sekunde, also ca. 37/8 = 4.625 MB/s. Immer noch weit ueber den Werten vom Threadersteller...
Die Fritzbox gehört mir. - Aber wie soll ich da bitte einen Terminal-Zugriff darauf bekommen?
Weiss nicht, ich nutze seit 2008 keine Fritzbox mit FritzOS mehr... Aber ich dachte mit Freetz ginge das?
An der Messkampagne von Breitbandmessung.de bion ich gerade dran. - Muss noch 34 Stunden warten bis ich die 11. Messung machen kann.
Mmmh, viel Erfolg! Ich habe immer noch den Verdacht, dass es der BNetzA nie darum ging das Testprozedere schnell oder endnutzerfreundlich zu gestalten. Der erhebliche Aufwand dient da vermutlich als Filter um die Anzahl abgeschlossener Kampagnen ueberschaubar zu halten...
Die BnetzA halt mit ihrer Zwitterrolle als "Vertreter der Endnutzer" und gleichzeitig "Partner der ISPs"... egal die Messregeln sind wie sie sind, in fruehestens 4 Tagen (und ein paar Stunden) solltest Du durch sein...
Wobei STRATO IMHO eine Marke von IONOS ist. Aber klar, Strato und hidrive moegen mit unterschiedlichem Routing arbeiten.
Hast Du Terminal-Zugriff auf Fritzbox? Vielleicht ist da aus irgendeinem Grund der Upload Trafficshaper aktiviert und falsch konfiguriert...
Ansonsten halt Messkampagne mit der Desktop-App von breitbandmessung.de machen und damit bei Stiegeler vorstellig werden. (Egal ob Du Kuendigen oder Miondern moechtest, die Existenz eines offiziellen Nachweises von Minderleistung kann helfen, dass Dein Anliegen ernster genommen wird).
Über die unterirdischen und fachlich absolut mangelhafte Qualifikation der Supportmitarbeiter sobald es über ein Reset hinausgeht, brauchen wir uns nicht weiter zu unterhalten. Das ist ein Fakt, leider.
Das ist IMHO allerdings bei allen Massenmarkt ISPs aehnlich, die 1. Linie des Kundensupports muss ein Rezept abarbeiten und wenn das Rezept nicht zum Problem passt ist das massive Zeitverschwendung fuer alle Beteiligten und fuer Kunden oft problematisch zu hoeheren Hotline-Levels durchzukommen wo eventuell mehr Hilfe geleistet werden kann.
Der Download laesst sich auch scripten, mit dem Vorteil dass wget die durchschittliche Downloadrate berechnet und angibt (zusaetzlich sieht mann eine instantane Schaetzung des aktuellen Durchsatzes)
user@RPi4BGPSNTP:~ $ wget -O /dev/null https://hidrive.ionos.com/api/sharelink/download?id=CIJRDRamj --report-speed=bits
--2025-01-10 10:44:31-- https://hidrive.ionos.com/api/sharelink/download?id=CIJRDRamj
Resolving hidrive.ionos.com (hidrive.ionos.com)... 85.214.3.95
Connecting to hidrive.ionos.com (hidrive.ionos.com)|85.214.3.95|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1830207094 (1.7G) [application/zip]
Saving to: '/dev/null'
/dev/null 100%[=====================================================================================================================================>] 1.70G 68.4Mb/s in 3m 33s
2025-01-10 10:48:04 (68.7 Mb/s) - '/dev/null' saved [1830207094/1830207094]Das ist vom einem 100/40 VDSL2 O2 Anschluss (via L3-BSA von der Telekom), hilft also vom Inhalt nicht weiter, zeigt aber wie mann die Messung komfortabel wiederholbar automatisieren kann, statt Screenshots vom Browser machen zu muessen.
Und hier der Vorwaerts-Trace, obwohl der reverse Trace hilfreicher waere, weil der in Lastrichtung ginge, der Vorwaertstrace beschreibt gerade mal den Weg des ACK Traffics.
user@RPi4BGPSNTP:~ $ mtr -ezbw -c 10 hidrive.ionos.com
Start: 2025-01-11T12:31:10+0100
HOST: RPi4BGPSNTP Loss% Snt Last Avg Best Wrst StDev
1. AS??? 192.168.42.1 0.0% 10 0.4 0.3 0.2 0.4 0.0
2. AS6805 loopback1.0004.acln.06.ham.de.net.telefonica.de (62.52.201.201) 0.0% 10 10.9 10.1 9.1 10.9 0.6
3. AS6805 bundle-ether11.0001.dbrx.06.ham.de.net.telefonica.de (62.53.7.108) 0.0% 10 10.6 10.8 10.1 11.7 0.5
4. AS6805 ae6-0.0001.corx.06.ham.de.net.telefonica.de (62.53.14.250) 0.0% 10 16.0 16.4 15.7 17.1 0.5
[MPLS: Lbl 16835 TC 0 S u TTL 1]
5. AS6805 bundle-ether5.0003.corx.02.ber.de.net.telefonica.de (62.53.0.47) 0.0% 10 17.6 17.1 16.1 17.8 0.6
[MPLS: Lbl 16835 TC 0 S u TTL 1]
6. AS6805 bundle-ether2.0001.cord.02.ber.de.net.telefonica.de (62.53.10.157) 0.0% 10 15.0 14.4 13.6 15.0 0.5
[MPLS: Lbl 16835 TC 0 S u TTL 1]
7. AS6805 ae0-0.0002.prrx.02.ber.de.net.telefonica.de (62.53.12.59) 0.0% 10 16.8 16.9 15.9 19.2 1.0
8. AS??? ionos.bcix.de (193.178.185.54) 0.0% 10 18.3 17.4 16.6 18.3 0.6
9. AS8560 lo-0-0.bb-a.rs.ber.de.net.ionos.com (212.227.117.77) 0.0% 10 17.0 20.6 16.4 50.6 10.5
10. AS8560 212.227.112.111 0.0% 10 16.8 18.6 16.6 25.2 2.7
11. AS6724 110.po18.sw-stg-core-1.10.as6724.net (85.214.2.101) 0.0% 10 17.0 16.6 15.9 17.0 0.4
12. AS6724 hidrive.ionos.com (85.214.3.95) 0.0% 10 16.9 16.8 16.2 17.4 0.5Ach ja, ein reverser Trace vom Server zu Dir nachhause waere auch hilfreich, zusaetzlich zur Vorwaertsrichtung 
Wenn Du ein Linux zu Verfuegung hast waere der Output der folgenden Programme hilfreich (eines reicht):
tracepath -b -4 hidrive.ionos.com
tracepath -b -6 hidrive.ionos.com
# die naechsten 2 brauchen ca. 100 Sekunden
mtr -ezb4w -c 100 -o LSNBAWVJMXI hidrive.ionos.com
mtr -ezb6w -c 100 -o LSNBAWVJMXI hidrive.ionos.com
# trippy/trip laeuft auch unter Windows: trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -4 hidrive.ionos.com
trip --mode tui --icmp-extensions --dns-lookup-as-info --tui-address-mode both --tui-icmp-extension-mode all --tui-preserve-screen --dns-resolve-method cloudflare -6 hidrive.ionos.com
So wie ich RFC6598 verstehe sind rfc1918 Adressen auch fuer CG-NAT valide nutzbar...
Privat heisst IMHO letztlich nur, dass diese Adressen (ohne Absprache) nicht ins freie Internet entschluepfen sollen/duerfen.
Die RFC1918 Adressen sind genau so valide wie RFC6598 Adressen... und 10.0.0.0/8 ist goesser als 100.64.0.0/10... der einzige Vorteil von RFC6598 ist das laut RFCs die nicht in provaten Endnetzen verwendet werden duerfen, aber Papier ist geduldig, nur weil ein RFC sagt MUST/MUST NOT ist das in Realitaet nicht zwingend so.
Das soll nicht heissen, dass es fuer ISPs nicht sinnvoll sein kann RFC6598 Adressen zu verwenden (und wenn nur damit die Zustaendigkeit erkennbar dokumentiert ist), aber IMHO ist das eine optionale (gute) Idee
Im Kontext von rfc1918 wuerde ich ala ISP eher 10.0.0.0/8 nutzen, bei 192.168.0.0/16 ist ja nur Platz fuer ca. 64 Tausend einzigartige Kunden... (klar, kann mann hinter jeder CG-NAT Box immer wieder die gleichen rfc1918 Adressen verwenden, mann macht sich allerdings das Leben damit selber schwer).
Die Telekom hat seit dem PR-technisch massiv dazu gelernt... fair-share klingt doch nett und positiv, und wer steht nicht auf der Seite des Underdogs (Telekom) gegen die Riesen des Silicon Valleys wie Meta?
Das ganze wird konsequent nicht verleugnet, aber auch nicht klar als das verbalisiert was es ist, vorsaetzliches Unterpeering. Und wie erwartet fuehrt dass dazu, dass all die Telekomversteher in den anderen Foren weiter davon schwadronieren, dass es keine harten Beweise gaebe...
Bloede Geschaeftspolitik, aber gute PR....
Telekom-Sprecherin Nicole Schmidt wies die Vorwürfe zurück. Sie sagte Golem.de: "Die erhobenen Vorwürfe sind falsch und zeugen von rechtlichem und technischem Unverständnis. Die Telekom verletzt weder die Netzneutralität, noch verschlechtert sie den Netzzugang für ihre Kundinnen und Kunden. Stattdessen gewinnen wir sämtliche Netztests und sind jüngst wieder – zum 17. Mal in Folge – als Anbieter des besten Internets ausgezeichnet worden."
Da wird also wie erwartet unter anderem der Sieg im Connect-Test herangezogen und ziemlich über-.interpretiert... weil wie in #44 gezeigt ist gerade eine einziger HTML-Test gegen ein AS das nicht mit der Telekom gut/teuer verbunden ist. Grütze ist das Wort was sich mir da aufdrängt, Marketinggrütze....
Wenn ich bei meiner 70+ Schwiegermutter auf die 7490 am o2 VDSL schaue, sehe ich deutlich mehr verügbare Bandbreite als in dem Uraltvertrag (o2 DSL S von Dezember 2017, Down 25 MBit/s - Up 5 MBit/s; wurde später ohne Mehrkosten von o2 verdoppelt) festgehalten wurde. Da o2/Telefonica sich von dem eigenen Netz getrennt hat und letztlich das Netz der Telekom seit einigen Jahren dahinter steckt, ist das Mehr an Bandbreite erklärbar.
Das Synclimit fuer den nominellen 50er Tarif war bei der Telekom lange
63680/12736
und wurde IMHO letztes Jahr auf
63680/23XXX
aufgewertet, die XXX Werte weiss ich nicht genau. Das haben die Reseller meine ich alle mitgemacht. EDIT: waren nicht alle Reseller, manche sind bei 50/10 geblieben...
Aber das geht nur wenn die Leitung nicht zu lang ist (was beim 50er immer noch laenger ist als beim 100er oder 250er)....
Zwischen haben und verwenden ist auch ein Unterschied. Den Data Lake muss man auch befahren können...
Mmmh, kann sein, die wenigen ISPs bei denen ich mit Technikern kommuniziere scheinen dazu in der Lage zu sein ;). Aber mir ist auch klar, dass z.B. die Telekom solche Zahlen lieber nicht in Marketingstudien wie dieser mit den Mitbewerbern teilt
Natürlich hast Du Recht, jedoch weiß ich aus meiner TK-Vergangenheit, dass kein Provider sein Netz zum Abfangen von Spitzen auslegt. Dies wäre sehr unwirtschaftlich. Allerdings kenne ich nicht mehr die Berechnungsgrundlagen für Bandbreitenerweiterungen.
Jein, im Mittel sollte die mittlere Spitzenlast schon abgedeckt werden können, aber wenn zur Spitzenzeit alle 32 Nutzer eines PON Segments meinen gleichzeitig einen Kapazitätstest machen zu müssen dürfte das einem ISP eher egal sein. D.h. bei einzelnen Nutzern darf es schon mal Zwacken und Zwicken, aber der Löwenanteil der Nutzer sollte nicht das Gefühl haben unter Minderleistung zu leiden, oder?
Was Berechnungsgrundlagen angeht habe ich leider keine relevante Ahnung und erspare uns meinen Spekulatius dazu
Außer den Leuten, die gerne schnell große Daten hoch/runterladen, wobei das eher ein „Quality of Life“ Upgrade ist, als wirklicher Bedarf, sehe ich keinen Anwendungsfall für die meisten Haushalte, der eine Bandbreite von mehr als den vielerorts möglichen 250 Mbits übersteigt.
Wobei die üblichen PONs (und auch DSLAMs) mit 32-64 Anschlüssen auch Limits haben welche mittlere Last/Anschluss tatsächlich geleistet werden kann:
GPON
32er Segmente:
2400/32 = 75 Mbps
1200/32 = 37.5 Mbps
64er Segmente
2400/64 = 37.5 Mbps
1200/64 = 18.75 Mbps
XGS-PON
32er Segmente:
8600/32 = 268.75 Mbps
64er Segmente:
8600/64 = 134.375 Mbps
Laut aktuellem Preseem Netzwerk-Report (Seite 25 der Praesentation) lag die mittlere Kapazitaetsnutzung zur Spitzenzeit 2024 (für die ISPs die Preseems Service nutzen) bei <= 10.5/2.0 Down/Up
Bei momentan wohl immer noch ein- bis niedrig zweistelliger mittleren Nutzung während der Primetime hat selbst ein 64er GPON noch gut Luft....
Die Studie nutzt statt der relevanten Größe mittlere Kapazitätsnutzung in der Spitzenzeit das ungünstige Mass monatliches Datenvolumen*, das ist allerdings eher kein Anfängerfehler, sondern Absicht da es hier nicht um echte Vorhersagen geht sondern darum dem Leser Handlungsbedarf einzureden...
Aber ich halte den Überbau der Kupfernetze durch Glasfaser trotzdem fuer eine mittel- und langfristig klar gute Idee. Und ich verstehe auch warum die Telekom versucht mit Studien wie dieser der Bevoelkerung FTTH schmackhaft zu machen....
*) Auch das monatliche Datenvolumen korreliert mit der Netzlast die ein ISP zu bändigen hat, aber IMHO halt deutlich schwächer als die mittlere Last in der Spitzenzeit, und kompetente ISPs wie hier die Telekom haben verlässliche Daten zur tatsächlichen Nutzung und müssen daher nicht mit groben Schätzeisen wie monatlichem Volumen operieren.
Nominal 250 MBit/s. D.h. nämlich nicht, das diese Datenraten auch tatsächlich an der TAE-Dose zur Verfügung stehen. Da spielen nämlich noch etliche physikalische Parameter mit hinein. Selbst 100er Anschlüsse erreichen die angegebenen max. Datenraten nicht.
Hängt davon ab, bei der Telekom ist das Synclimit (fuer Vollsync)
VDSL100: 116.800 / 46.720
VDSL250: 292.032 / 46.720
Und das kommt auch an... bzw. in etwa der zu erwartende Durchsatznetto von:
116.800 * 64/65 * ((1500-8-20-20)/(1500-8+34)) = 109.43
292.032 * 64/65 * ((1500-8-20-20)/(1500-8+34)) = 273.60
46.720 * 64/65 * ((1500-8-20-20)/(1500-8+34)) = 43.77
wenn die Leitung ausreichend kurz ist und nicht gestoert wird... ich kann allerdings nicht sagen welcher Anteil der Leitungen Vollsync bekommt...
Danke!
Ganz im Ernst, dass der Datenverbrauch steigen wird ist klar, allerdings unklar wie stark und in wie weit und wie schnell der Kapazitätsbedarf ansteigen wird.
Diese "Auftrags-Studie" sollte mann, wie ähnliche "Studien" nicht überbewerten, die Telekom hat ein Produkt das sie an den Kunden (Glasfaser) bringen will und hat bisher keine bessere Idee als das über die damit mögliche Kapazität zu verkaufen/bewerben. Da kommt so eine Studie gerade recht die versucht darzulegen, dass schon mittelfristig DSL-Kapazitaeten nicht mehr reichen werden.
Ist halt Marketinggrütze
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
