Glasfaser Nordwest Ausbau

  • Eine hohe Latenz zu einem Router hat genau 0(!) Aussagekraft bezüglich der Leitungsqualität.


    Die Router ist hoch optimierte Kisten, die aus zwei Bestandteilen stehen. Einer Controlplane mit CPU sowie einer Dataplane. Die Dataplane ist hochoptimiert auf die Weiterleitung/Routing von Paketen anhand bestimmter Parameter. Die Controlplane schreibt diese Parameter in die Dataplane. Die Dataplane benötigt für das Weiterleiten von Paketen die Controlplane theoretisch gar nicht.


    Was passiert jetzt also bei einem ICMP Echo Request? Das Paket wird von der Dataplane an die Controlplane weitergeleitet und die CPU des Routers (die in der Regel gar nicht mal soviel Leistung haben), müssen die Pakete in CPU beantworten und wieder zurück schicken.


    1. Kann diese ICMP Antwort auch länger dauern, da es nicht die top Priorität eines Routers ist ICMP Pakete zu beantworten.

    2. Wird die Anzahl an ICMP Paketen pro Sekunde auf Routern oft begrenzt, um die CPU vor Überlastung (z.B. ICMP Flood) zu schützen.


    Dementsprechend kann es passieren, dass einzelne Hops, gar nicht oder verzögert antworten. Das hat aber mit der Verbindungsqualität nichts zu tun. Dort ist nur die Latenz am Ziel entscheidend.


    Disclaimer: Das Verhalten eines Routers ist stark vereinfacht


    Edit: Was ist das Ziel des ersten Screenshots? Auf dem zweiten Screenshot ist die Latenz bei 17ms und der Jitter bei ca. 1ms. Ist doch alles top? Und Shadow ist auch nicht gerade für ihr gutes Peering bekannt (wie man merkt, da es über die Telekom - AS3320 geht, statt direkt über den DE-CIX oder ähnliches)

  • Aus einer hohen Latenz oder hohem Packet Loss bei einem Router in der Mitte eines Traceroutes kann man nicht schließen, dass der Router ein Problem hat, ganz besonders dann nicht, wenn dahinter wieder normale Werte kommen. Die Erklärung hat Waishon schon geliefert. An dem Wert des nächsten Routers ist die Control Plane des vorherigen Routers nicht beteiligt.


    Für den Packet Loss auf der ganzen Strecke gilt im Prinzip ähnliches: Du testest mit einem Protokoll, das die Router mit niedrigster Priorität auf dem schwächsten Teil des Routers verarbeiten.


    Idealerweise würdest du mit einem normalen Nutzdatenprotokoll und gegen Server in verschiedenen Netzen testen, ob auch dabei Packet Loss auftritt. 1% Paketverluste sind nämlich schon ziemlich übel, aber eben nur, wenn sie real auftreten, und das misst man nicht mit Traceroute. Router kümmern sich um ICMP als letztes und die Verarbeitung hat nichts mit dem Teil des Routers zu tun, der deine Pakete durchleitet.

  • Bis zu dem Beitrag lief das Streaming ohne Probleme.

    Welcher Beitrag?

    Über was für ein Streaming reden wir denn hier? Video Streaming? Kann ja eigentlich nicht sein, denn dabei würden Delays wenig bis gar nicht stören.


    Also geht es im Game Straming? Stadia oder dieses nVidia Angebot oder ähnliches? Oder geht es um "reguläre" Onlinegames mit lokalem Spiel, die über einen Gaming Server zusammengeschaltet werden?

  • Der Beitrag den ich Samstag geschrieben habe.

    Echtzeitvideostreaming.
    Genau, ist wie Stadia oder geforce-now.

    Der Stream kann nicht wie bei Netflix vor puffern, weil es ja meine Eingaben verarbeitet und das den Videofeed (Mein Cloud-PC) zu mir zurückschickt.

  • Das ist momentan natürlich die Königsdisziplin für einen Internetzugang.


    Ich weiß nicht genau, welche Protokolle bei diesen Diensten zum Einsatz kommen, ob TCP oder UDP. Bei einem Paketmitschnitt für Wireshark könnte man prinzipiell für einen TCP Stream auswerten, ob es Retransmissions gibt. Für UDP wird das schwierig, da diese Dinge auf Applikationsebene geregelt werden. Aufgrund der Charakteristik der Anwendung vermute ich eher, dass es UDP ist.


    Da im Grunde jeder Router und auch der Server für diese Probleme verantwortlich sein kann, hast du praktisch keine Chance, wirklich nachzuweisen, dass die EWE Infrastruktur das Problem ist. Ich halte das auch für eher unwahrscheinlich. Ich denke, das Problem wird am ehesten auf Serverseite entstehen.

  • Wie schon erwartet läuft ein Großteil der Kommunikation über UDP. TCP Pakete, offenbar für Kontrollinformationen, sind dazwischen. Die sind aber verschlüsselt.

    Die Kommunikation sieht absolut unauffällig aus. Auch die TCP Streams sind bis auf zwei oder drei Pakete komplett frei von Unregelmäßigkeiten. Bei der großen Anzahl an Paketen ist das völlig unerheblich.


    Natürlich kann man in die UDP Pakete nicht reinschauen. Aber die TCP Streams sind sehr unauffällig. Ein größeres Problem auf der Übertragungsstrecke gibt es definitiv nicht. Wenn du Probleme mit der Darstellung hast, liegt das Problem auf deinem PC oder auf dem Server.

  • Also im Client kann man auswählen:
    Geschwindigkeit bevorzugen: UDP
    Stabilität bevorzugen: TCP

    Ich verwendet die Shadow Ghost, das ist wie eine "Set-Top-Box" für Shadow.
    Strom rein, Internet rein, USB rein, HDMI rein = Shadow Stream.
    Mehr als den Streaming Part kann die Box auch nicht übernehmen.
    Man kann natürlich auch den Client auf einen PC packen und von dort aus ganz normal streamen.

    Ist dann halt die Frage, an Hardware (Ghost) nix geändert, also wirds diesmal an Shadow liegen

  • Du findest dieses Forum hier toll und möchtest es unterstützen? Großartig! Hier zeigen wir dir eine Möglichkeit, wie du uns supporten kannst. Es kostet dich keinen Cent mehr und das Forum bleibt hiermit weiter werbefrei.

    Amazon Link

    Nutze diesen Button um bei Amazon einzukaufen. Das kostet dich keinen Cent mehr, jedoch bekommen wir eine kleine Provision.
    Bei Amazon einkaufen und das GF unterstützen
    Mehr Infos gibt es in diesem Thread
  • Wie hast du die Ghost ins Heimnetz integriert? Per LAN oder WLAN?


    Wie gesagt, man kann in den Streams nichts erkennen. Ich hab mir noch mal explizit bei einigen TCP Streams die Dauer zwischen Request und ACK angesehen, die ist immer unter 20 ms. Das ist ein hervorragender Wert. Da wird also auch nichts verzögert oder so. Zumindest nicht in den TCP Streams.

  • [Blockierte Grafik: https://cdn.discordapp.com/att…99196/20210717_141506.jpg][Blockierte Grafik: https://cdn.discordapp.com/att…93696/20210717_144159.jpg]20210717_144446.jpg (3024×4032) (discordapp.com)[Blockierte Grafik: https://cdn.discordapp.com/att…74654/20210717_144446.jpg]





    Nochmal an einem anderen PC getestet, in den beiden letzten Bildern, läuft ein Bali 2160p Video über den Shadow zum testen.
    Habe da nochmal länger Wireshark laufen lassen.
    Download

    Mit freundlichen Grüßen

  • Das sind klassische Paketverluste? In den Screenshots steht was von Verbindungsabbrüchen - was auch immer das in dem Kontext bedeutet.


    Gehen wir davon aus, dass es sich tatsächlich um klassische Paketverluste handelt: Die treten dann auch im Leerlauf auf. Wie ist das zu erklären?

  • Leerlauf:
    Wenn sich nichts auf dem Bildschirm bewegt, und ich nichts mache wird ja trotzdem mein Desktop von Shadow gestreamt, auch dabei können wohl Verluste in der Videoübertragung auftreten.
    Merken tut man dies natürlich erst wenn man aktiv im Stream etwas macht. (Spielen, Browser, Videos etc.)

    FAQ1
    FAQ2

  • Mit einem Paketverlust von 2-3% selbst bei geringer Last müsste der Anschluss nahezu unbrauchbar sein. Du kannst mal versuchen, ob du nachvollziehbare Werte mit iPerf3 messen kannst. Es gibt ein paar wenige öffentliche UDP-Gegenstellen für iPerf3. Mit folgendem Aufruf testest du die Downstream-Richtung mit UDP und einer Bandbreite von 40Mbit/s. Das scheint die ungefähre Zieldatenrate des Streams zu sein. Wenn möglich, dann mach die Messung mit einem Linux-System, das per Kabel am Router angeschlossen ist.


    iperf3 -c ping.online.net -p 5208 -R -u -b 40M


    iPerf3 gibt dir nach 10 Sekunden eine Zusammenfassung mit der übertragenen Datenmenge, Jitter und verlorenen Paketen. Ich bekomme da 0% Packet Loss und 0,5ms Jitter an einem DG-Anschluss.

  • Wenn sich nichts auf dem Bildschirm bewegt, und ich nichts mache wird ja trotzdem mein Desktop von Shadow gestreamt, auch dabei können wohl Verluste in der Videoübertragung auftreten.

    Ich hätte aber erwartet, dass sich das dann trotzdem in den FPS wiederspiegelt, denn auch beim Desktop werden ja FPS erzeugt. Da sind aber Passagen, wo die FPS und die Datenrate 0 ist und trotzdem Paketverluste aufgezeichnet werden.


    Die Idee mit dem UDP iperf ist eine gute Idee als Test. Ich komme auf ähnliche Werte wie alfalfa

    Code
    1. iperf3 -c ping-ams1.online.net -p 5206 -R -u -b 40M
    2. [...]
    3. [ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
    4. [ 4] 0.00-10.01 sec 47.7 MBytes 40.0 Mbits/sec 0.000 ms 0/0 (0%)
  • Komische iPerf3 Versionen habt ihr da. Warum zeigen die die Gesamtzahl der Pakete nicht an? So sieht das bei mir aus:


    [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams

    [ 5] 0.00-1.00 sec 4.31 MBytes 36.2 Mbits/sec 0.381 ms 0/3121 (0%)

    [ 5] 1.00-2.00 sec 4.77 MBytes 40.0 Mbits/sec 0.349 ms 0/3455 (0%)

    [ 5] 2.00-3.00 sec 4.77 MBytes 40.0 Mbits/sec 0.365 ms 0/3453 (0%)

    [ 5] 3.00-4.00 sec 4.77 MBytes 40.0 Mbits/sec 0.368 ms 0/3451 (0%)

    [ 5] 4.00-5.00 sec 4.77 MBytes 40.0 Mbits/sec 0.348 ms 0/3455 (0%)

    [ 5] 5.00-6.00 sec 4.77 MBytes 40.0 Mbits/sec 0.337 ms 0/3454 (0%)

    [ 5] 6.00-7.00 sec 4.76 MBytes 40.0 Mbits/sec 0.385 ms 0/3450 (0%)

    [ 5] 7.00-8.00 sec 4.77 MBytes 40.0 Mbits/sec 0.363 ms 0/3455 (0%)

    [ 5] 8.00-9.00 sec 4.77 MBytes 40.0 Mbits/sec 0.375 ms 0/3452 (0%)

    [ 5] 9.00-10.00 sec 4.77 MBytes 40.0 Mbits/sec 0.384 ms 0/3453 (0%)

    - - - - - - - - - - - - - - - - - - - - - - - - -

    [ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams

    [ 5] 0.00-10.00 sec 47.7 MBytes 40.0 Mbits/sec 0.000 ms 0/34199 (0%) sender

    [ 5] 0.00-10.00 sec 47.2 MBytes 39.6 Mbits/sec 0.384 ms 0/34199 (0%) receiver

  • Du findest dieses Forum hier toll und möchtest es unterstützen? Großartig! Hier zeigen wir dir eine Möglichkeit, wie du uns supporten kannst. Es kostet dich keinen Cent mehr und das Forum bleibt hiermit weiter werbefrei.

    Amazon Link

    Nutze diesen Button um bei Amazon einzukaufen. Das kostet dich keinen Cent mehr, jedoch bekommen wir eine kleine Provision.
    Bei Amazon einkaufen und das GF unterstützen
    Mehr Infos gibt es in diesem Thread

Erstelle ein Benutzerkonto oder melde dich an um zu kommentieren

Du musst ein Benutzerkonto haben um einen Kommentar hinterlassen zu können

Benutzerkonto erstellen
Neues Benutzerkonto für unsere Community erstellen. Geht einfach!
Neues Benutzerkonto erstellen
Anmelden
Du hast bereits ein Benutzerkonto? Melde dich hier an.
Jetzt anmelden