Beiträge von onurbi

Zitat von Bracew

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.

Zitat von Tyler

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?

Zitat von Bracew

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!

Zitat von Bracew

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

Von DG kam heute die Antwort: Das Problem sei gefunden und soll bis 5.12.20 gelöst sein.

Es bleibt spannend!

Zitat von alfalfa

Hier ist die volle Bandbreite schon mit einem Thread (-P 1) verfügbar. So sollte das auch sein. Mehrere Threads kaschieren Netzprobleme und stehen bei vielen Anwendungen nicht zur Verfügung. Mit mehr als einem Thread misst man also nicht das, was z.B. eine einzelne HTTP(S)-Verbindung erreichen würde. Ich würde bei iPerf3 noch die Option -Z empfehlen, weil dadurch die CPU-Last gesenkt wird. Ein guter Testserver ist speedtest.wtnet.de (Ports 5200-5209).

Richtig!

Die Versionen 3.9 und 3.7 (andere habe ich gerade nicht hier) akzeptieren -Z oder --zerocopy nicht , obwohl es im help mit aufgelistet wird. Interessant!

Zitat von Alfy

Es scheint also, wie von alfalfa vermutet, ein regionale Problem zu sein. Mein Anschlüsse befinden ich im PLZ-Gebiet 415xx.

Code: Hier eine iperf3-Parameter:

iperf3 -c <SERVER> -p <PORT> -i 1 -V -t 600 -P 20 -R -4 -O 5 -T "Down"
iperf3 -c <SERVER> -p <PORT> -i 1 -V -t 600 -P 20 -4 -O 5 -T "Up"

Zu meiner Verwunderung reichen zu guten Zeiten 3-4 Threads aus (-P 4).

Zu den Fehlerzeiten beobachte ich ab ca. 16 keine Steigerung mehr. Aber universell lieber mehr, als weniger!

Zitat von alfalfa

Meine Vermutung ist, dass regionale Infrastruktur so lange mit neuen Kunden beaufschlagt wird, bis es nicht mehr geht...

Genauso isses!

Aber man muss sich eigentlich auf der Zunge zergehen lassen, dass der gebuchte Tarif keine "bis zu" Überbuchungsangabe ist, wie bei der DOCSIS, sondern "garantiert" ist. Es steht bloß nirgends, was passiert, wenn sie mal doch niedriger ist...

Hallo Tommy-b,

mit welcher Software hast Du den Graphen erzeugt? Vor allem, was zeigt er?

Servus,

kann mich da gleich anschließen. Ich habe den Tarif DG400..

Meine Messergebnisse muss ich in IPv4- und IPv6-Verkehr und auch die Uhrzeit trennen.

Auch bei mir (8er PLZ) geht der IPv4 Verkehr im Downstream ab ca. 19:30 Uhr mit bis zu 2Mb/s massiv in die Knie. Der Upstream bleibt dabei meist bei 80Mb/s.

Gemessen habe ich unter Win10 mit einem I7 Laptop und dem eingebauten 1G Interface mit dem Programm Speedtest.net (also nicht mit der Weboberfläche von Ookla). Leider zeigt das Programm nicht an, ob der Anbieter der Gegenstelle IPv4 oder IPv6 macht. Deshalb habe ich mit Wireshark nachgesehen. Anbieter mit den langsamen Werten verwendeten IPv4.

Händle&Korte, Philunet oder Incas z.B. verwenden z.B. IPv6. Wähle ich die aus, sehe ich auch am Abend erfreuliche 413 im DS und 209 im US.

Morgens ab 8 Uhr bekomme ich diese Werte bei allen Anbietern zu Gesicht. Um diese Uhrzeit wundere ich mich aber, dass die US Werte bei IPv6 Anbietern auf 60-80Mb/s runtergehen, während sie bei IPv4 auf 209 bleiben. Hat da jemand eine Idee?

Die Erklärung für den abendlichen Einbruch sehe ich im wohl überlasteten CG-NAT Server. Ich arbeite auch bei einem Internetanbieter (nee, nee schreibe jetzt nicht welcher!!) und wir hatten den Kunden das gleiche Problem zugemutet. Ist nicht meine Abteilung, habe es aber mitbekommen.

Übrigens decken sich die Messwerte recht gut, wenn man iperf3 statt Speedtest,net verwendet!

Ich habe ein Ticket bei DG offen und habe gestern einen interessanten Anruf von einem Techniker bekommen, der auf Grund des Tickets bei mir vorbeikommen sollte. Er bestätigte mir, dass er von Kunden seit 14 Tagen, sprich Anfang November, Beschwerden bearbeitet, die genau das selbe Bild haben! Ich habe ihm dann gesagt, dass er nicht vorbeikommen muss, er meinte dann auch, dass er halt nur einen Speedtest machen würde. Das macht keinen Sinn.

Mit den Daten habe ich DG schon versorgt. Da ich von uns weiß, dass der Aufwand wohl nicht niedrig ist (sowohl kosten-, als auch manpowermäßig), die Kapazität zu erweitern, sehe ich schwarz, dass da bald was passiert.

Habe im Ticket um Rückruf von der Fachabteilung gebeten. Bin sehr gespannt, ob der erfolgt! Die weiß doch genau woran es hakt und weiß eigentlich nicht, was sie mir erzählen soll.