Deutsche Glasfaser - Performance bei Netzen im Aufbau

  • Habe exakt das gleich Problem. 1000 Mbit/s Anschluss bei DG mit DG-TV.

    Abends, ca. 20-23 Uhr, bricht die Downloadgeschwindigkeit zeitweise auf 10-20 Mbit/s ein. Tagsüber noch nicht gemessen.

    PLZgebiet 33178.

  • ....in den Abendstunden.

    Wenn ich mir die Messwerte meines RasPi ansehe, kann ich keine Besonderheit "...in den Abendstunden" sehen.

    Stärken und Schwächen sind über den ganzen Tag verteilt, aber es werden zu keiner Zeit die versprochenen Download-Übertragungsraten:

    Zitat

    Download:

    Maximale Übertragungsrate: 1000 Mbit/s

    Normale Übertragungsrate: 900 Mbit/s

    Minimale Übertragungsrate: 900 Mbit/s

    der Deutsche Glasfaser erreicht.

  • Wenn ich mir die Messwerte meines RasPi ansehe, kann ich keine Besonderheit "...in den Abendstunden" sehen.

    Stärken und Schwächen sind über den ganzen Tag verteilt, aber es werden zu keiner Zeit die versprochenen Download-Übertragungsraten:

    der Deutsche Glasfaser erreicht.

    Misst dein Raspi im IPv4 oder IPv6 Netz? Oder beides?

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Auf meinem RasPi ist der Speedtest installiert. Die Ergebnisse der Windows-Version hat auch der freundliche Mitarbeiter von Deutsche Glasfaser sehen wollen. Auf dem RasPi ist es eine Kommandozeilenversion.

    Aufgrund der Ausgabe "Testing from Deutsche Glasfaser (94.31.97.235)" gehe ich von IPv4 aus.

  • Hallo,

    ich wollte mich auch mal zum Thema äussern.

    Wir haben seit ein paar Monaten 400/200 Mbit Glasfaser von DG und befinden uns im PLZ-Bereich 38xxx.

    Dort sind auch tägliche Schwankungen in den Abendstunden zwischen 19-23 Uhr zu sehen.

    Ich messe natürlich auch regelmäßig die Geschwindigkeiten.

    Im Anhang ein Beispiel von den letzten Tagen

    Ich habe noch kein Ticket aufgemacht, werde dies aber nächste Woche nachholen.
    Insgesamt muss ich aber sagen, dass ausserhalb der Problemzeiten in der Regel die 400/200 Mbit sehr gut anliegen.

    Einmal editiert, zuletzt von Tyler (26. November 2020 um 13:04)

  • Auf meinem RasPi ist der Speedtest installiert. Die Ergebnisse der Windows-Version hat auch der freundliche Mitarbeiter von Deutsche Glasfaser sehen wollen. Auf dem RasPi ist es eine Kommandozeilenversion.

    Aufgrund der Ausgabe "Testing from Deutsche Glasfaser (94.31.97.235)" gehe ich von IPv4 aus.

    Ja, deswegen merkst du wahrscheinlich auch nicht viel davon. Richtig schlimm ist es mit IPv6.

    Laut der Störung Seite sind Wartungsarbeiten für NRW / Delbrück für den 2 Dezember angekündigt. Bin mir nicht sicher ob damit nur die Stadt Delbrück gemeint ist oder ob dort ein Knotenpunkt ist und es die ganzen Problemfälle betrifft.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Ich glaube die laufen alle über IPv6 wenn verfügbar. Was Linux angeht müssten dich aber andere beraten.

    Ich habe bei DG Nachgefragt ob die Wartungsarbeiten in Delbrück etwas mit dem Problem zutun haben. Wohl nicht:

    Zitat

    Nein mit der Wartung hängt das meiner Meinung nach nicht zusammen, da da Problem flächendeckend herrsch, soweit ich das beurteilen kann.

    Die Kollegen konnten schon einiges beheben es sollte also nicht mehr in allen Bereichen in diesem ausmaß auftreten. Teste das doch bitte heute Abend nochmal und sende mir morgen gern einen Speedtest, ich leite den dann nochmal weiter, damit die Kollegen wissen, wo es noch Kunden gibt bei denen das nicht behoben ist.

  • (Seit drei Wochen lasse ich von einem Raspberry Pi 4 die Geschwindigkeit alle 20 Minuten messen und protokollieren, siehe Anlage.)

    Hast Du einen bestimmten Server mit --server verwendet?

    Mir fällt mit Speedtest.net unter Windows auf, dass am Abend der IPv4 Verkehr langsam wird. Mit Händle&Korte (ipv6) ergeben sich auch Abends meine Sollwerte (400/200), Mit der Deutschen Telekom (IPv4) jedoch nicht.

    Auch ich stelle unter Tags fest, dass die IPv4 Upstreamwerte mit bestimmten Servern höher sind, als die für den Downstream.

    Mein Raspi 4 schafft zwar im lokalen Netz zu einem Windows iperf3 Server in beiden Richtungen um die 980Mb/s, aber mit iperf3 und speedtest-cli sind die höchsten DS-Werte nur um die 300Mb/s. Das haben auch schon andere festgestellt: https://forum-raspberrypi.de/forum/thread/4…-download-rate/

    Mit welchem Programm hast Du die Grafik erzeugt?

    Einmal editiert, zuletzt von onurbi (28. November 2020 um 08:57)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Welcher Speedtest funktioniert rein über IPv6?

    Bei Speedtest.net sucht man sich die passende Gegenstelle aus. Bei Händle&Korte, Philunet und Incas konnte ich über Wireshark sehen, dass der Test über IPv6 läuft.

    Unter Tags ist der Downstream sogar mit unter IPv4 damit schneller. Das kann ich mir überhaupt nicht erklären. Eigentlich dürfte nur der CG-NAT Server der DG durch Überlastung bremsen. Sehr merkwürdig!

  • Ich messe natürlich auch regelmäßig die Geschwindigkeiten. Im Anhang ein Beispiel von den letzten Tagen

    Deine Messungen entsprechen auch meinen Beobachtungen. Der Graph sieht gut aus. Da möchte ich auch gerne hin.

    Mit welcher Software auf welchem Rechner misst Du? Wie stellst Du die Werte dar?

  • Hast Du einen bestimmten Server mit --server verwendet?

    Nein. Da ich bisher nicht wusste, welche die schnelleren sind.

    Nach meiner Auswertung zeigen sich die Spieleserver als die schnelleren, z.B. GameAdicted, Spacken.net, Gigaspeedsurfer.

    Aber auch diese schwanken.

    Schade, dass DG keinen eigenen Speedtest Server als Gegenstelle zur Verfügung stellt. Dann könnte man nur die eigen Anbindung testen.

    Mein Raspi 4 schafft ..... nur um die 300Mb/s.

    Auf meiner Auswertung sehe ich, dass mein Raspi manchmal Werte von über 700 Mbit/sec erreicht und im Durchschnitt von ca. 150 Messungen zu Spacken.net 471 Mbit/sec bei 824 Mbit/sec maximal und 42 Mbit/sec minimal.

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

    Ich wäre sehr skeptisch gegenüber Messungen von einem System, das nicht mal mitten in der Nacht die Anschlussbandbreite erreicht.

    Speedtest.net testet mit TLS. Das treibt die Prozessorlast hoch und ist für schwachbrüstige Systeme wie ARM SBCs keine gute Wahl.

    Der Speedtest von Deutsche Glasfaser arbeitet mit der Technik von Ookla (Speedtest.net) und einem Server der DG.

    Der bei Speedtest.net auswählbare Server von Wilhelm.tel ist für DG-Kunden gut geeignet: Wilhelm.tel ist ebenfalls ein FTTH-Provider und hat folglich Interesse daran, dass der Speedtest auch mit hohen Bandbreiten jenseits von VDSL brauchbare Messergebnisse liefert. DG peert mit Wilhelm.tel, also misst man nicht irgendwelche knappen Netzübergänge oder Transit-Umwege.

    Wilhelm.tel stellt auch andere (bessere) Messverfahren unter http://speedtest.wtnet.de/ bereit. Damit sind u.a. gezielte Messungen mit IPv4 und IPv6 möglich.

  • Schade, dass DG keinen eigenen Speedtest Server als Gegenstelle zur Verfügung stellt. Dann könnte man nur die eigen Anbindung testen.

    Auf meiner Auswertung sehe ich, dass mein Raspi manchmal Werte von über 700 Mbit/sec erreicht und im Durchschnitt von ca. 150 Messungen zu Spacken.net 471 Mbit/sec bei 824 Mbit/sec maximal und 42 Mbit/sec minimal.

    Wie alfalfa schreibt, hat DG inzwischen auch einen Ookla Server. Sein Traffic ist IPv6 und zeigt mir um 1/.40 (noch) Nennwerte an. Bin mal auf den Abend gespannt!

    Ja, ist mir durchaus aufgefallen, dass bei Dir auch höhere Spitzen im Graphen zu sehen sind. Bin noch dran, Ursachen zu prüfen, die beim Raspi 4 die Diskrepanz zwischen lokal OK und nach draußen dann doch begrenzen ausmachen.

    Einmal editiert, zuletzt von onurbi (28. November 2020 um 17:49)

  • Wilhelm.tel stellt auch andere (bessere) Messverfahren unter http://speedtest.wtnet.de/ bereit. Damit sind u.a. gezielte Messungen mit IPv4 und IPv6 möglich.

    Den kannte ich noch nicht, danke!

    Auch deshalb interessant, weil ich ja auch meinen eigenen iperf3 Server im Firmennetz (München) am Laufen habe und dorthin schlechtere DS-Raten bekomme (unter 400 Soll) als zu wtnet! Man könnte jetzt meinen von Borken aus ist es nach Norderstedt näher als nach München :=)

    Zumindest ist es zu wtnet ein Hop weniger, als zu meinem Server. Aber das alleine ist natürlich nicht maßgeblich!

    Der Server selbst ist es nicht. von meinem Arbeitsplatz aus bekomme ich 980Mb/s in beiden Richtungen. Mal die Kollegen nerven!

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Wilhelm.tel stellt auch andere (bessere) Messverfahren unter http://speedtest.wtnet.de/ bereit.

    Diese Seite und den Server kannte ich auch noch nicht. Auch vielen Dank.

    Ich habe natürlich gleich ein paar Tests gemacht gegen den wilhelm.tel iPerf3 Server. Völlig unrepräsentativ. Gerade eben und nur einzelne.

    Aber für mich trotzdem sehr verwirrende:

    IPerf3 mit IPv4
    IPerf3 mit IPv4 (reverse) IPerf3 mit IPv6 IPerf3 mit IPv6 (reverse)
    Desktop PC
    mit Windows 10
    510 Mbits/sec
    360 Mbits/sec 470 Mbits/sec 380 Mbits/sec
    Desktop PC
    mit Debian 10
    510 Mbits/sec 350 Mbits/sec 490 Mbits/sec 380 Mbits/sec
    RasPi 4 mit
    Raspbian 10
    510 Mbits/sec 900 Mbits/sec 500 Mbits/sec 890 Mbits/sec

    Alle Werte auf ±10 gerundet. Der Desktop PC kann Dual-Boot.

    Warum ist reverse am RasPi schneller als normal?

    wget auf dem RasPi 4 mit Raspbian 10:

    wget auf dem Desktop PC mit Debian 10:

    Erkenntnis, der Raspi ist schneller. Bei 108 MB/s gehe ich von Megabyte aus, also mal 8 = 860 MBit/sec., oder?

    860 MBit/sec. würde auch meinem gebuchtem DG giga 1000 Tarif

    - Download:

    - Maximale Übertragungsrate: 1000 Mbit/s

    - Normale Übertragungsrate: 900 Mbit/s

    - Minimale Übertragungsrate: 900 Mbit/s

    schon recht nahe kommen.

    3 Mal editiert, zuletzt von Bracew (28. November 2020 um 19:09)

    • Offizieller Beitrag

    "Reverse" ist bei iperf3 die Server-zu-Client Richtung, in diesem Fall also der Download. Die "normale" Richtung ist vom Client zum Server, also i.d.R. der Upload. Unter Linux kann man die CPU-Last von iperf3 auf der Clientseite mit der Option -Z (--zerocopy) noch weiter senken.

    Die niedrigen Downstreamwerte des Desktop-PCs sollte man abklären, z.B. mal ein anderes Kabel verwenden (auch mal abgeschirmt oder unabgeschirmt) oder den Port am Switch/Router wechseln. Es bietet sich auch an, den Test zwischen Desktop-PC und Raspberry Pi auszuführen, mit dem PC jeweils mal als Server und als Client.

    Die Downloadrate von wget ist mit Vorsicht zu genießen. Man sollte es nicht zu genau nehmen. Die "1000mb.bin" Datei von speedtest.wtnet.de ist z.B. 1.024.000.000 Byte groß. Wget zeigt die Größe als 976,56M an. Die Datenrate passt weder zum einen noch zum anderen Wert. Der Protokolloverhead (HTTP, TCP, IP, Ethernet) wird auch nicht angegeben. In kleineren Tarifen wird die Datenrate von der DG überprovisioniert, damit nicht andauernd Beschwerden über diesen nicht sichtbaren Teil der tatsächlich bereitgestellten Bandbreite kommen. Im Gigabit-Tarif geht das nicht.

  • Mein Raspi4 liefert mit speedtest.wtnet.de jetzt endlich nachvollziehbare Werte für den DG400!

    Das iperf3 Laufintervall ist 5 Sekunden alle 15 Minuten mit 2 Minuten Offset (also 07, 17, 37, 47) mit den Ports 5202-5205 (IPv4 DS/US IPv6 DS/US) so dass wir uns möglichst nicht in die Quere kommen.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Die niedrigen Downstreamwerte des Desktop-PCs sollte man abklären

    Danke für den Hinweis. Volltreffer!

    Mein Desktop-PC hat eine Onboard-LAN-Buchse auf dem Motherboard, welche ich jetzt einige Jahre nicht genutzt hatte. Mit dieser funktionierte zwar Windows aber nicht Linux. Statt die Onboard-LAN-Buchse zu nutzen hatte ich eine TP-Link Gigabit PCI-Karte (TG-3269) genutzt. Diese lief im Dual-Boot.

    Nun habe ich mal wieder die Onboard-LAN-Buchse versucht. Hiermit erreicht der Desktop-PC nun auch die 900 MBit/sec., wie der RasPi.

    Auch unter Linux wird die Onboard-LAN-Buchse nun erkannt und genutzt. Die PCI-Karte ist ausgebaut und wird aufs Altenteil geschickt.

    Der RasPi erreicht die Werte auch, siehe Beitrag 116.

    Somit Ende gut, alles gut. Mein DG giga 1000 Anschluß im PLZ Bereich 34225 erreicht seine Soll-Werte.

    P.S.:

    Für mich nur seltsam, dass der eigene Test der DG nicht auf die Werte kommt:

    Einmal editiert, zuletzt von Bracew (29. November 2020 um 14:02)

  • Na dann wollen wir mal hoffen, das das bei Dir (euch) da in 34225 so bleibt. Lt. letztem HNA-Bericht seid ihr gerade in der Anschlussphase, sprich Aktivierungsphase, richtig?

    Wenn das so ist:

    Bei uns in 34270 (ist ja quais nebenan) war das ja genauso. In der ersten Zeit der Aktivierungen war alles im grünen Bereich. Tolle Geschwindigkeiten, rel. guter Ping usw.

    Jetzt nähert sich die Aktivierungsphase wohl dem Ende zu und schon ist das Elend da. Siehe auch meine Vorberichte.

    Seit letzter Meldung an die DG und dem Telefonat mit dem Service habe ich hier nichts weiter gehört. Mal sehen ob sich das noch ändert. Wenn nicht werde ich spätestens Mitte Dez. da wieder mit meinen Protokollen aufschlagen.

    Es kann und darf ja nicht sein, das solche Beschwerden ins Nirwana laufen. Zumindest erwarte ich mal eine Rückmeldung per eMail und ggf. auch einen Lösungsansatz dazu.

    Gruß

    Enter