Langsame Downloads von IONOS (Hidrive) - Problem nur von DG-Anschlüssen ausgehend (Peering-Problem?)

    Hallo zusammen,

    ich habe einen Cloud-Storage bei IONOS, bei dem mir seit längerem sehr langsame Download-Raten (von meinem DG-Anschluss ausgehend) von ~350 Kbps auffallen. Grundsätzliche Performance (Ping, Speedtests, etc.) zu anderen Seiten/Servern ist i.O. (Ping: 8 ms, Down: 417 Mbps / UP: 207 Mbps).

    Erst war ich von einem Problem auf Seiten IONOS ausgegangen und habe dort ein entsprechendes Ticket eröffnet. Jedoch konnte dort kein Problem ausgemacht werden und als ich den Demo-Download von einem anderen ISP aus gestartet habe, lief es problemlos schnell.

    Deshalb habe ich die Vermutung das es ggf. ein Peering-Problem zwischen dem Netz der DG und 1&1 / IONOS gibt...
    (Ich habe bereits an anderen DG-Anschlüssen von Bekannten getestet und auch dort läuft es sehr langsam.)

    Ein entsprechendes Ticket beim DG-Support wurde bislang immer mit Standard-Textbausteinen ala "Überprüfen Sie bitte Ihren Anschluss / Router / etc." beantwortet. Auf den begründeten Verdacht wird leider nicht eingegangen... :(

    Zum Test habe ich eine 3 GB große Demo-Datei zum Download freigegeben: https://hidrive.ionos.com/lnk/Syuq4JtTR

    Für mich wäre interessant zu erfahren ob ihr (sofern ihr einen DG-Anschluss habt) ebenfalls eine sehr langsame Download-Geschwindigkeit habt? So könnte man regionale Probleme ausschließen bzw. mit größerer Sicherheit festmachen, das es sich um ein generelles Problem auf Seiten der Deutschen Glasfaser handelt.

    Vielen Dank vorab! ;)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Moin, Sworzi bestätigt somit das es an DG liegen muss.
    Vom Telekom Glasfaser 600/300 in Berlin
    Laut Trace müsste der Server in Berlin stehen (oder hier gespiegelt.) Es sind in eigentlich sogar nur ca.3ms, da mein MoCa Netzwerk zur FritzBox schon 3ms auffrisst. ;)

    Nachtrag:
    Ja, anscheinend steht der Server hier in Berlin, mit 2 x 100GBit Anbindung

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    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)

    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.

    Bei mir (DG 1000/500) genauso: DL von my.hidrive.com erfolgt tagezeitunabhängig mit max. 20 Mbit/s.

    Was mich wundert: Ich habe im gleichen RZ von Strato in Berlin eine VM, die problemlos 300 Mbit/s+ liefert - wer es testen möchte:

    http://82.165.122.247/1Gb.dat
    http://[2a01:239:2f9:9a00::1]/1Gb.dat

    trotzdem ist das Routing suboptimal - obwohl IONOS direkte Peerings am De-CIX, B-CIX und AMS-IX hat (siehe: https://www.peeringdb.com/net/262 ) läuft die Rückroute über Abox.net und zayo:

    Reverse-Trace (von meiner VM zu DG:):

    Wenn es aber über zayo zur DG keinen Engpass gibt, und Hidrive aus anderen Netzen (z.B. Telekom) ebenfalls performant ist, dann müsste das wohl bedeuten, dass HiDrive in Richtung DG doch eine andere Route nimmt als meine VM im gleichen Rechenzentrum - das ist sehr merkwürdig.

    Mal eine Rückmeldung von mir (DG, GPON, 400/200): die Downloadgeschwindigkeit bewegt sich zwischen 250 und 290 Kilobyte/s. Ich wollte die eins bis zwei Stunden nicht abwarten, daher die Bereichsangabe und kein Mittelwert.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    kammann in einem großen und professionell betriebenen RZ (z.B. Telekom, NTT, Interaxion,...) hast Du nie nur einen Internetaccess-Provider, sondern die Auswahl in zwei- und manchmal auch dreistelliger Anzahl. Da kann es durchaus sein, das zwei Housing/Hosting-Anbieter auf dem gleichen Campus unterschiedliche Internetaccess-Provider und Bandbreiten gebucht haben.

    Nochmal ein Messwert von heute mit wget. Gestern ca. 2 MB/s und heute ca. 4,5 MB/s. DG 400/200

    Wget Messung

    wget -O /dev/null https://hidrive.ionos.com/api/sharelink/…ad?id=CIJRDRamj --report-speed=bits
    --2025-01-11 15:49:18-- https://hidrive.ionos.com/api/sharelink/…ad?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 36.6Mb/s in 5m 43s

    2025-01-11 15:55:01 (42.7 Mb/s) - ‘/dev/null’ saved [1830207094/1830207094]

    Hier noch ein mtr Wert

    mtr

    mtr -ezbw -c 10 hidrive.ionos.com
    Start: 2025-01-11T16:01:29+0100
    HOST: PC04 Loss% Snt Last Avg Best Wrst StDev
    1. AS??? PC04.mshome.net (172.25.112.1) 0.0% 10 0.3 0.3 0.3 0.6 0.1
    2. AS??? fritz.box (192.168.x.x) 0.0% 10 1.5 1.5 1.1 1.6 0.2
    3. AS??? 100.124.1.16 0.0% 10 6.1 5.4 3.5 7.2 1.1
    4. AS??? ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
    5. AS60294 185.22.46.64 0.0% 10 5.3 4.7 3.3 6.5 1.2
    6. AS??? et-0-1-0.core-ams14.as6724.net (80.249.210.180) 0.0% 10 31.2 31.9 29.7 34.0 1.4
    7. AS8560 lo-0-0.bb-a.rs.ber.de.net.ionos.com (212.227.117.77) 0.0% 10 31.2 32.3 30.3 34.6 1.3
    8. AS8560 212.227.112.105 0.0% 10 31.1 37.4 31.1 53.3 6.8
    9. AS6724 110.po18.sw-stg-core-2.11.as6724.net (85.214.2.99) 0.0% 10 30.9 31.4 29.7 32.9 1.2
    10. AS6724 hidrive.ionos.com (85.214.3.95)

    Einmal editiert, zuletzt von Sworzi (11. Januar 2025 um 16:05)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

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

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.

    Bei der deutschen Glasfaser wird man häufig über die Niederlande geroutet. Das Unternehmen hat ursprünglich niederländische Wurzeln, dahin war der Draht schon immer gut (im Sinne der Anbindung an die große weite Welt).

    Aber richtig: Auf dem Weg nach Berlin ist aus Deutschland ein Ausflug nach Amsterdam eher ungünstig. Allerdings: Das ist ein Hop von Strato in Amsterdam. Jedenfalls ist da der Sprung im Delay, auch wenn man bei den Paketverlusten nichts sieht.

    Könnte also wirklich eine Frage des Rückwegs sein, wie bereits vermutet.