1. Startseite
  2. Artikel
  3. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  4. Forum
  5. Digital Signage Info
  6. Glasfaserinternetanbieter bewerten
  7. Blog
    1. Artikel
  • Anmelden
  • Registrieren
  • Suche
Dieses Thema
  • Alles
  • Dieses Thema
  • Dieses Forum
  • Artikel
  • Seiten
  • Forum
  • Blog-Artikel
  • Erweiterte Suche
  1. Glasfaserforum.de - Das Informations- und Hilfeforum rund um das Glasfaser-Internet.
  2. Forum
  3. Alles über das Glasfaser-Internet
  4. Glasfaser-Technik: Modem, Router, Netzwerk & Verkabelung

GPON Jitter und Latenz im Netz der DG

  • Rxyzr
  • 26. April 2024 um 19:49
  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 26. April 2024 um 19:49
    • #1

    Hallo,

    Erstmal zu mir ich habe einen DG Privatkundenanschluss (Classic 400 - Baujahr 2019) also 400/200 mit GPON Topologie. In den Städten in der nähe habe ich bekannte mit FTTH Anschlüssen der Glasfaser Nordwest(ISP Telekom - GPON) und der EWE(Osnatel - AON), nach Rücksprache mit den bekannten ist mir aufgefallen das der Jitter also die Abweichung der Latenz im Netz der Deutschen Glasfaser hier wesentlich höher ist als z.B. im Netz der Telekom über Glasfaser Nordwest obwohl dort auch GPON zum Einsatz kommt, dort liegt der Jitter bei ca 0,3-0,6ms. Und im AON Netz der EWE bei 0-0,2ms. Selbst der DSL Anschluss meiner Oma über O2(Technik von EWE) liegt bei 0,2-0,4ms. Klar hängt davon auch viel vom Routing und Peering ab aber dieses Phänomen ist auch zum First-Hop auf Anbieterseite der Fall. Um dieses Problem nun zu beheben habe ich einen Dateiupload zu einem Server im Internet gestartet, diesen Upload habe ich auf 100Mbit/s begrenzt und zack: Der Jitter liegt nun bei 0,5ms. Im Anhang findet ihr einen Screenshot(gelb Markierte nach Upload, Unmarkiert vor Upload). Nun zur eigentlichen Frage: Ist der Jitter bei euren DG GPON Anschlüssen auch so hoch, bzw. bei anderen GPON Anschlüssen niedriger und was denkt ihr woran liegt das hauptsächlich? Ich würde jetzt mal auf die 1:64 Splitter tippen(je mehr Kunden desto längere Wartezeit bis ein Nutzer senden darf = höherer Jitter). GFNW/Telekom setzt ja meistens auf 1:16/1:32 maximal und selbst Nachts ist der Jitter bei mir unverändert hoch. Natürlich ist das meckern auf hohem Niveau aber ich denke das so etwas bei einem FTTH Netz nicht vorkommen sollte. Ich danke für jegliche Rückmeldung LG Rxyzr/Hannes

    Bilder

    • ponlatenz.png
      • 41,29 kB
      • 590 × 425
  • frank_m
    Erleuchteter
    Reaktionen
    770
    Beiträge
    4.935
    • 26. April 2024 um 19:59
    • #2
    Zitat von Rxyzr

    Ich würde jetzt mal auf die 1:64 Splitter tippen(je mehr Kunden desto längere Wartezeit bis ein Nutzer senden darf = höherer Jitter).

    Dann müsste dein Upload Test das Ergebnis aber verschlechtern, da die wenigen Ressourcen, die du bekommst, jetzt neben dem Ping auch noch von anderen Daten benutzt werden wollen.

    Ich tippe eher auf niedrige Priorität bei ICMP Paketen. Teste mal mtr mit UDP Paketen. Und mach die Tests via IPv6, nicht IPv4, weil da ein NAT Router dazwischen ist.

  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 26. April 2024 um 20:16
    • #3
    Zitat von frank_m

    Dann müsste dein Upload Test das Ergebnis aber verschlechtern, da die wenigen Ressourcen, die du bekommst, jetzt neben dem Ping auch noch von anderen Daten benutzt werden wollen.

    Ich tippe eher auf niedrige Priorität bei ICMP Paketen. Teste mal mtr mit UDP Paketen. Und mach die Tests via IPv6, nicht IPv4, weil da ein NAT Router dazwischen ist.

    Das ist ja das komische, habe den Upload der Datei ja auch 100 Mbit begrenzt, mein Anschluss bietet ja 210 Mbit/s Netto, wenn ich den Upload nicht begrenze steigt der Jittert, passiert ca ab 160 Mbit durchgehendem Upload, beim Download steigt die Latenz/Jitter generell, macht ja auch Sinn. Mit IPv6 sieht es bei ICMP genauso aus. Wenn ich einen MTR per UDP mache läuft das nur mit IPv4, und auch nur in einem großen Intervall, sonst hab ich Loss von 90% aufwärts. Bei IPv6 kommt der nie weiter als mein Router egal welches Ziel ich benutze.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • frank_m
    Erleuchteter
    Reaktionen
    770
    Beiträge
    4.935
    • 26. April 2024 um 21:03
    • #4

    Ja, stimmt, mtr via UDP geht irgendwie nicht richtig.

    Ich hab ja einen AON Anschluss, und da sehe ich folgendes:

    • IPv4 ist schlechter, als IPv6
    • Jitter ist maßgeblich vom Ziel abhängig
    • Die ersten Hops des Providers sind ganz schlechte Ziele. Riesiger Jitter von 2 ms und mehr
  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 26. April 2024 um 21:32
    • #5

    Mit AON sollte es mit ICMP trotzdem wesentlich besser sein, der Business DG Anschluss unserer Schule hat vllt 0,1-0,3ms. Wie sieht es denn bei dir aus zu Cloudflare und Google? Und wie groß ist der Unterschied zwischen v4 und v6

  • frank_m
    Erleuchteter
    Reaktionen
    770
    Beiträge
    4.935
    • 26. April 2024 um 22:19
    • #6

    Hier mal die Ergebnisse:

    Code
    pi@raspi:~ $ ping -c 20 1.1.1.1 (Cloudflare)
    PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
    64 bytes from 1.1.1.1: icmp_seq=1 ttl=58 time=6.67 ms
    64 bytes from 1.1.1.1: icmp_seq=2 ttl=58 time=5.48 ms
    64 bytes from 1.1.1.1: icmp_seq=3 ttl=58 time=5.34 ms
    64 bytes from 1.1.1.1: icmp_seq=4 ttl=58 time=5.55 ms
    64 bytes from 1.1.1.1: icmp_seq=5 ttl=58 time=5.62 ms
    64 bytes from 1.1.1.1: icmp_seq=6 ttl=58 time=5.07 ms
    64 bytes from 1.1.1.1: icmp_seq=7 ttl=58 time=5.25 ms
    64 bytes from 1.1.1.1: icmp_seq=8 ttl=58 time=5.55 ms
    64 bytes from 1.1.1.1: icmp_seq=9 ttl=58 time=5.28 ms
    64 bytes from 1.1.1.1: icmp_seq=10 ttl=58 time=5.21 ms
    64 bytes from 1.1.1.1: icmp_seq=11 ttl=58 time=5.24 ms
    64 bytes from 1.1.1.1: icmp_seq=12 ttl=58 time=5.40 ms
    64 bytes from 1.1.1.1: icmp_seq=13 ttl=58 time=5.47 ms
    64 bytes from 1.1.1.1: icmp_seq=14 ttl=58 time=5.18 ms
    64 bytes from 1.1.1.1: icmp_seq=15 ttl=58 time=5.04 ms
    64 bytes from 1.1.1.1: icmp_seq=16 ttl=58 time=5.39 ms
    64 bytes from 1.1.1.1: icmp_seq=17 ttl=58 time=5.24 ms
    64 bytes from 1.1.1.1: icmp_seq=18 ttl=58 time=5.27 ms
    64 bytes from 1.1.1.1: icmp_seq=19 ttl=58 time=5.47 ms
    64 bytes from 1.1.1.1: icmp_seq=20 ttl=58 time=5.46 ms
    
    --- 1.1.1.1 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19031ms
    rtt min/avg/max/mdev = 5.040/5.408/6.669/0.327 ms
    
    
    
    pi@raspi:~ $ ping -c 20 8.8.8.8 (Google)
    PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
    64 bytes from 8.8.8.8: icmp_seq=1 ttl=118 time=11.2 ms
    64 bytes from 8.8.8.8: icmp_seq=2 ttl=118 time=10.0 ms
    64 bytes from 8.8.8.8: icmp_seq=3 ttl=118 time=10.4 ms
    64 bytes from 8.8.8.8: icmp_seq=4 ttl=118 time=10.2 ms
    64 bytes from 8.8.8.8: icmp_seq=5 ttl=118 time=9.82 ms
    64 bytes from 8.8.8.8: icmp_seq=6 ttl=118 time=9.91 ms
    64 bytes from 8.8.8.8: icmp_seq=7 ttl=118 time=9.93 ms
    64 bytes from 8.8.8.8: icmp_seq=8 ttl=118 time=9.91 ms
    64 bytes from 8.8.8.8: icmp_seq=9 ttl=118 time=9.94 ms
    64 bytes from 8.8.8.8: icmp_seq=10 ttl=118 time=10.0 ms
    64 bytes from 8.8.8.8: icmp_seq=11 ttl=118 time=9.68 ms
    64 bytes from 8.8.8.8: icmp_seq=12 ttl=118 time=10.1 ms
    64 bytes from 8.8.8.8: icmp_seq=13 ttl=118 time=9.85 ms
    64 bytes from 8.8.8.8: icmp_seq=14 ttl=118 time=9.92 ms
    64 bytes from 8.8.8.8: icmp_seq=15 ttl=118 time=10.1 ms
    64 bytes from 8.8.8.8: icmp_seq=16 ttl=118 time=10.1 ms
    64 bytes from 8.8.8.8: icmp_seq=17 ttl=118 time=10.2 ms
    64 bytes from 8.8.8.8: icmp_seq=18 ttl=118 time=9.90 ms
    64 bytes from 8.8.8.8: icmp_seq=19 ttl=118 time=10.4 ms
    64 bytes from 8.8.8.8: icmp_seq=20 ttl=118 time=10.0 ms
    
    --- 8.8.8.8 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19026ms
    rtt min/avg/max/mdev = 9.678/10.075/11.169/0.302 ms
    
    pi@raspi:~ $ ping -c 20 2606:4700:4700::1111 (Cloudflare IPv6)
    PING 2606:4700:4700::1111(2606:4700:4700::1111) 56 data bytes
    64 bytes from 2606:4700:4700::1111: icmp_seq=1 ttl=59 time=5.07 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=2 ttl=59 time=4.60 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=3 ttl=59 time=4.66 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=4 ttl=59 time=4.84 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=5 ttl=59 time=4.71 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=6 ttl=59 time=4.59 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=7 ttl=59 time=4.58 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=8 ttl=59 time=4.71 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=9 ttl=59 time=4.66 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=10 ttl=59 time=4.69 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=11 ttl=59 time=4.67 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=12 ttl=59 time=4.59 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=13 ttl=59 time=4.69 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=14 ttl=59 time=4.83 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=15 ttl=59 time=4.90 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=16 ttl=59 time=4.57 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=17 ttl=59 time=4.62 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=18 ttl=59 time=4.58 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=19 ttl=59 time=4.63 ms
    64 bytes from 2606:4700:4700::1111: icmp_seq=20 ttl=59 time=4.68 ms
    
    --- 2606:4700:4700::1111 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19033ms
    rtt min/avg/max/mdev = 4.571/4.693/5.065/0.123 ms
    
    
    pi@raspi:~ $ ping -c 20 2001:4860:4860::8844 (Google IPv6)
    PING 2001:4860:4860::8844(2001:4860:4860::8844) 56 data bytes
    64 bytes from 2001:4860:4860::8844: icmp_seq=1 ttl=119 time=9.93 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=2 ttl=119 time=9.08 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=3 ttl=119 time=9.05 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=4 ttl=119 time=9.14 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=5 ttl=119 time=10.1 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=6 ttl=119 time=9.09 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=7 ttl=119 time=9.15 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=8 ttl=119 time=9.05 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=9 ttl=119 time=9.05 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=10 ttl=119 time=9.08 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=11 ttl=119 time=9.15 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=12 ttl=119 time=9.06 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=13 ttl=119 time=9.10 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=14 ttl=119 time=9.24 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=15 ttl=119 time=9.29 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=16 ttl=119 time=8.99 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=17 ttl=119 time=9.02 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=18 ttl=119 time=9.19 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=19 ttl=119 time=9.05 ms
    64 bytes from 2001:4860:4860::8844: icmp_seq=20 ttl=119 time=9.07 ms
    
    --- 2001:4860:4860::8844 ping statistics ---
    20 packets transmitted, 20 received, 0% packet loss, time 19026ms
    rtt min/avg/max/mdev = 8.994/9.194/10.123/0.287 ms
    
    pi@raspi:~ $
    Alles anzeigen

    Einmal editiert, zuletzt von frank_m (27. April 2024 um 10:31)

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 27. April 2024 um 01:49
    • #7

    Ist ja wesentlich stabiler als bei mir, würde deswegen tippen dass es teilweise schon an der PON Architektur liegt, wenn ICMP bei der DG unterpriorisiert wäre müsste es bei dir ja nicht anders aussehen.

  • Edding
    Profi
    Reaktionen
    143
    Beiträge
    615
    • 27. April 2024 um 13:10
    • #8

    Es kommt drauf an wie die Zeitschlitze konfiguriert sind(Max PON Burst Size und Polling Rate), DG scheint da wohl eher eine konservative Konfiguration zu fahren die Overhead spart.

  • cyan
    Reaktionen
    19
    Beiträge
    31
    • 18. November 2025 um 06:49
    • #9

    Thread Wiederbelebung mit einer Beobachtung:

    Den beschriebenen GPON-Jitter bei der DG im Bereich von ca. 1-5 ms on top auf die minimal mögliche Latenz habe ich auch mit meiner 400er Leitung seit jeher gehabt.

    Ich habe mich jetzt auf den Gigabit Tarif upgraden lassen und der Jitter ist komplett weg. Ping ist nun bei ping -4 www.heise.de -t bei 5-6 ms "wie festgenagelt". Vorher waren es 5-10 ms schwankend.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 18. November 2025 um 07:53
    • #10
    Zitat von cyan

    Thread Wiederbelebung mit einer Beobachtung:

    Den beschriebenen GPON-Jitter bei der DG im Bereich von ca. 1-5 ms on top auf die minimal mögliche Latenz habe ich auch mit meiner 400er Leitung seit jeher gehabt.

    Ich habe mich jetzt auf den Gigabit Tarif upgraden lassen und der Jitter ist komplett weg. Ping ist nun bei ping -4 www.heise.de -t bei 5-6 ms "wie festgenagelt". Vorher waren es 5-10 ms schwankend.

    Moin, diese feststellung hatte ich auch, habe damals auch noch auf einen DG Giga Tarif umgestellt und der jitter war dann auch auf einmal verschwunden. Scheint wohl echt mit den Bandbreiten-Profilen zusammenzuhängen. Mich würde dann nur mal interessieren wie es nun bei den neuen 500/300/100 Tarifen im Vergleich aussieht. Also ob der Jitter je besser der Tarif ist kleiner wird, oder ob der Jitter überall "schlecht" und nur beim 1000er gut ist :).

  • pufferueberlauf
    Meister
    Reaktionen
    666
    Beiträge
    2.502
    • 18. November 2025 um 08:07
    • #11

    Das spraeche dann gegen die Qualitaet des Schedulers des OLTs....

    Oh Wunder ueber Wunder Sparausbau mit PON-Gruetze bleibt hinter den Erwartungen zurueck... ;)

    Waere spannend das mal mit IRTT zu testen um zu sehen ob bei jittrigen Links die Probleme in Up- oder Download-Richtung entstehen oder in beiden...

    Einmal editiert, zuletzt von pufferueberlauf (18. November 2025 um 10:55)

  • Rxyzr
    Fortgeschrittener
    Reaktionen
    37
    Beiträge
    290
    • 18. November 2025 um 10:21
    • #12
    Zitat von pufferueberlauf

    Das sprsaeche dann gegen die Qualitaet des Schedulers des OLTs....

    Oh Wunder ueber Wunder Sparausbau mit PON-Gruetze bleibt hinter den Erwartungen zurueck... ;)

    Waere spannend das mal mit IRTT zu testen um zu sehen ob bei jittrigen Links die Probleme in Up- oder Download-Richtung entstehen oder in beiden...

    Wer hätte es gedacht:D. Leider habe ich den Anschluss aufgrund eines Umzugs nicht mehr und habe nun wesentlich stabileres DSL. Wäre trotzdem spannend wenn cyan dies testen könnte.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Online
    mbo77
    Erleuchteter
    Reaktionen
    921
    Beiträge
    3.635
    • 18. November 2025 um 11:11
    • #13

    Hängt vielleicht auch von der Auslastung ab.

    Ich kann aktuell nicht sehen, wie ausgelastet mein konkretes Segment ist. Aber im 500/250-Profil (GPON) habe ich einen Jitter von ca. 0,5 ms. Das geht also auch in PON.

  • Edding
    Profi
    Reaktionen
    143
    Beiträge
    615
    • 18. November 2025 um 11:43
    • #14

    Min Latenz und Jitter sind hauptsächlich Konfigurationssache in einem PON.

  • cyan
    Reaktionen
    19
    Beiträge
    31
    • 18. November 2025 um 14:21
    • #15
    Zitat von Edding

    Min Latenz und Jitter sind hauptsächlich Konfigurationssache in einem PON.

    Richtig, mit der Auslastung hatte das nie was zu tun in meinen Fällen.

    Zitat von pufferueberlauf

    Waere spannend das mal mit IRTT zu testen um zu sehen ob bei jittrigen Links die Probleme in Up- oder Download-Richtung entstehen oder in beiden...

    Kann jetzt nicht mehr die alte Konfiguration testen, dafür müsste ich mich zurückstellen lassen ;)

    Zitat von mbo77

    Ich kann aktuell nicht sehen, wie ausgelastet mein konkretes Segment ist. Aber im 500/250-Profil (GPON) habe ich einen Jitter von ca. 0,5 ms. Das geht also auch in PON.

    Interessant. Vielleicht sind dann nur die alten Produkte (Produktportfolio 2018) davon betroffen. Der 500er Tarif ist ja aus dem neueren Produktportfolio (2023). Evtl. hängen an den Produkten auch Traffic shaper Profile. Aber das ist reine Spekulation.

  • Tipp: Jetzt kostenlos registrieren, mitmachen und das Forum ohne Werbebanner nutzen.
  • Online
    mbo77
    Erleuchteter
    Reaktionen
    921
    Beiträge
    3.635
    • 18. November 2025 um 14:38
    • #16

    Ich bin ja zum Glück nicht Kunde bei DG.

Glasfaseranbieter jetzt bewerten

Du bist mit deinem Glasfaseranbieter (un)zufrieden?

Dann nutze unsere community-getriebene Bewertungsplattform glasfaseranbieter.de - jetzt mit dem Glasfaserforum Login unkompliziert bewerten!

Jetzt in wenigen Sekunden fair bewerten!
  1. Datenschutzerklärung
  2. Impressum
Community-Software: WoltLab Suite™ 6.2.6

Wir respektieren Deine Privatsphäre

Wir nutzen Cookies und ähnliche Technologien für den Betrieb der Seite, Reichweitenmessung und Werbung. Du entscheidest, was Du erlaubst. Details in unserer Datenschutzerklärung. Deine Auswahl kannst Du jederzeit über den Link „Cookie-Einstellungen“ im Fußbereich ändern.

Cookie-Einstellungen

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