Unitymedia Latenzen IPv4 vs. IPv6

[CPirasa]

Hi,

gibt es Unterschiede bei den Latenzen zwischen IPv4 und IPv6? Oder eventuell sogar bei verschiedenen Bandbreiten?

Ich wohne in einem 3 Parteien Haus im Erdgeschoss und habe noch einen relativ alten Vertag - 3 Play 50 mit einer IPv4.
Mein Schwager über mir hat ein 2 Play 120 mit DSLite.
Sofern ich mich mit dem WLAN meines Schwagers verbinde und Online Spiele, komme ich auf Pings ~15ms.
Einige Minuten später mache ich das gleiche mit meinem Zugang sprich IPv4 habe ich eineb Oing von ~35ms.

Habe das jetzt schon oft getestet und ich kam immer auf das gleiche ergebnis.

Hat jemand dahingehend Infos?

Grüße

 

[Soldierofoc]

Ein Traceroute wäre interessant. Ggf. kommt die Differenz auch schon zum Teil durch dein/sein internes Netzwerk.

 

[#DiRK]

Ich habe in den meisten Fällen bessere Latenzen unter v6 (statt unter v4 mit DS-Lite). Geschätzt ca. 10-20%. Ich vermute, dass bei IPv4 einfach ein völlig überlasteter AFTR das Problem ist. Freue mich also wenn die Server meines Lieblings-MMORPG hoffentlich bald unter v6 betrieben werden.

 

[hajodele]

Vor allem habt ihr andere Router.

 

[Soldierofoc]

Deswegen wäre ja hauptsächlich interessant wann die Differenz auftritt...

 

[pmb]

Kann es sein, dass dein Router Wlan auf dem 2,4Ghz Netz sendet, der andere auf dem 5,0Ghz (-> Wlan ac)? Das würde deine Diskrepanz erklären. Ist dein Ping denn über den ganzen Tag gleich? Überlege auch zu Unitymedia zu wechseln, habe aber ein bisschn Angst vor DS-Lite

 

[addicted]

Joa, ohne traceroute lässt sich überhaupt nichts sagen.

Ansich hilft aber DSLite nicht. Das zusätzliche Tunneln erhöht die Latenz nur. Wenn also alles andere identisch wäre (TM), wäre v4 nativ schneller als v4 in DSLite.

v4 und v6 Latenzen zu vergleichen macht überhaupt keinen Sinn, denn das sind komplett unterschiedliche Protokolle, die haben überhaupt nichts miteinander zu tun.
Stell es Dir vor wie verschiedene Kontinente: Du brauchst nicht überlegen, ob es in Südamerika länger dauert, von Kerpen nach Köln zu fahren, weil es beide dort garnicht gibt.

 

[CPirasa]

Stimmt natürlich das man die IPv4 und IPv6 nicht direkt vergleichen kann. Da gebe ich zu, den Titel etwas falsch gewählt zu haben.
Sollte in diesem natürlich xxx vs. DSLite bedeuten.

Das sieht hier alles Harmloser aus als es in Wirklichkeit ist.

DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 * * * Zeitüberschreitung der Anforderung. 2 9 ms 8 ms 7 ms 84.116.197.141 3 12 ms 12 ms 11 ms 84.116.196.194 4 22 ms 24 ms 18 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198] 5 15 ms 21 ms 16 ms de-fra01b-ri1-ae0-0.aorta.net [84.116.134.6] 6 20 ms 13 ms 13 ms te0-0-2-3.c150.f.de.plusline.net [80.81.192.132] 7 * * * Zeitüberschreitung der Anforderung. 8 13 ms 21 ms 12 ms 212.19.61.13 9 13 ms 12 ms 14 ms redirector.heise.de [193.99.144.80]
Ablaufverfolgung beendet.
------
Ping wird ausgeführt für heise.de [193.99.144.80] mit 32 Bytes Daten:
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=15ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=12ms TTL=247
Ping-Statistik für 193.99.144.80: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 12ms, Maximum = 15ms, Mittelwert = 12ms

Nicht DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 9 ms 9 ms 7 ms 192.168.0.1 2 * * * Zeitüberschreitung der Anforderung. 3 14 ms 13 ms 15 ms 81.210.131.100 4 19 ms 38 ms 20 ms 84.116.196.194 5 25 ms 31 ms 29 ms de-fra01b-rc1-ae17-0.aorta.net [84.116.197.198] 6 29 ms 17 ms 35 ms de-fra01b-ri1-ae0-0.aorta.net [84.116.134.6] 7 23 ms 18 ms 20 ms te0-0-2-3.c150.f.de.plusline.net [80.81.192.132] 8 * * * Zeitüberschreitung der Anforderung. 9 15 ms 16 ms 21 ms 212.19.61.13 10 34 ms 16 ms 17 ms redirector.heise.de [193.99.144.80]
Ablaufverfolgung beendet.
-----
Ping wird ausgeführt für heise.de [193.99.144.80] mit 32 Bytes Daten:
Antwort von 193.99.144.80: Bytes=32 Zeit=23ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=29ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=26ms TTL=247
Antwort von 193.99.144.80: Bytes=32 Zeit=20ms TTL=247
Ping-Statistik für 193.99.144.80: Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0 (0% Verlust),
Ca. Zeitangaben in Millisek.: Minimum = 20ms, Maximum = 29ms, Mittelwert = 24ms

Grüße

 

[CPirasa]

Mir geht es nur darum, zu verstehen, warum das so ist.
Werden DS-Lite Leitungen ggf. Provisioniert?

DS-Lite:

Nicht DS-Lite:

Grüße

 

[pmb]

Ehm, kannst du vielleicht eben kurz den Wlan-Faktor irgendwie ausschließen? Ein Kollege mit nativer ipv4 und Lan-Anschluss hat immer so 10-20ping bei Unitymedia deutschen Servern.

 

[CPirasa]

Wäre in diesem Fall blödsinn. Der DSLite Anschluss ist weiter entfernt und geht durch die Decke und ist trotzdem "Schneller".?

Beide Netze bediene ich per 2.4 GHz WLAN.

Ich habe eine ConnectBox non-dslite mein Schwager hat ein TC7200 dslite.

Standort ist übrigens Bielefeld - plz 33607.

Grüße

 

[addicted]

Nicht DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 9 ms 9 ms 7 ms 192.168.0.1

Nach dem ersten Hop würd ich nicht mehr weiter suchen.

 

[Gizeh775]

Als mein Anschluss kurzzeitig von DS-Lite auf native IPv4 umgestellt wurde habe ich beobachtet, dass ich auf einmal am Bodensee das UM-Netz verlassen habe, vorher war es bei Stuttgart, ich komme aus der Nähe von Stuttgart, also würde ich bei so "Auffälligkeiten" grundsätzlich mal in die Richtung denken.

 

[CPirasa]

Nicht DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 9 ms 9 ms 7 ms 192.168.0.1

Nach dem ersten Hop würd ich nicht mehr weiter suchen.

Zu meiner ConnectBox sind es 4 Meter Luftlinie.

Durchaus möglich, das es am WLAN liegt.jedoch: Der DSLite Anschluss ist weiter entfernt, muss durch ne Decke und ist ein TC7200 - auch über wlan. Oder ist die LAN Seite der ConnectBox tatsächlich so behämmert?

 

[Dragon]

Als mein Anschluss kurzzeitig von DS-Lite auf native IPv4 umgestellt wurde habe ich beobachtet, dass ich auf einmal am Bodensee das UM-Netz verlassen habe, vorher war es bei Stuttgart, ich komme aus der Nähe von Stuttgart, also würde ich bei so "Auffälligkeiten" grundsätzlich mal in die Richtung denken.

Woran hast du das festgestellt? Mit einem der sehr unzuverlässigen GeoIP-Dienste?

 

[johnripper]

Nicht DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 9 ms 9 ms 7 ms 192.168.0.1

Nach dem ersten Hop würd ich nicht mehr weiter suchen.

Zu meiner ConnectBox sind es 4 Meter Luftlinie.

Durchaus möglich, das es am WLAN liegt.jedoch: Der DSLite Anschluss ist weiter entfernt, muss durch ne Decke und ist ein TC7200[emoji23] - auch über wlan. Oder ist die LAN Seite der ConnectBox tatsächlich so behämmert?

Hallo!! 9 bzw. 7ms zum ersten Hop zeigt dir doch deutlich, dass du mal erstmal in deiner interen Konfiguration den Fehler suchen solltest. Dort ist alleine eine Schwankung von 28% mal abgesehen von den mind. 7ms (!!!) auf 4 Meter (!!!).
Sämtliche Speedtest empfehlen im übrigen nicht umsonst eine LAN-Konfiguration und du kommst hier permanent mit WLAN.

Vorher macht alles keinen Sinn.

 

[Gizeh775]

Als mein Anschluss kurzzeitig von DS-Lite auf native IPv4 umgestellt wurde habe ich beobachtet, dass ich auf einmal am Bodensee das UM-Netz verlassen habe, vorher war es bei Stuttgart, ich komme aus der Nähe von Stuttgart, also würde ich bei so "Auffälligkeiten" grundsätzlich mal in die Richtung denken.

Woran hast du das festgestellt? Mit einem der sehr unzuverlässigen GeoIP-Dienste?

UM-Netz verlassen ist eh falsch ausgedürckt, sagen wir ins Liberty Global Routing einsteigen.
Ich geh einfach mal davon aus, dass Liberty Global (aorta.net) seine Hostnames nicht aus Spaß und Langeweile nach deutschen Städten wählt...
und wenn ich üblich erstmal REU STR und dann FRA habe und dann auf einmal KOB STR FRA scheint sich was an dem Einstiegspunkt geändert zu haben :>


-

An den TE, kannst du es einfach mal mit einem Kabel testen, damit man den WLAN-Faktor mal rausnehmen kann? oO

Nicht DS-Lite

<i>
</i>Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 9 ms 9 ms 7 ms 192.168.0.1

Nach dem ersten Hop würd ich nicht mehr weiter suchen.

Zu meiner ConnectBox sind es 4 Meter Luftlinie.

Durchaus möglich, das es am WLAN liegt.jedoch: Der DSLite Anschluss ist weiter entfernt, muss durch ne Decke und ist ein TC7200 - auch über wlan. Oder ist die LAN Seite der ConnectBox tatsächlich so behämmert?

Oder willst du hiermit sagen dass du mit LAN 9ms hast?
Falls dem so ist:
Mal mit einem anderen PC testen, Router mal neustarten, usw....

 

[addicted]

9 bzw. 7ms zum ersten Hop zeigt dir doch deutlich, dass du mal erstmal in deiner interen Konfiguration den Fehler suchen solltest. Dort ist alleine eine Schwankung von 28%!

Davon abgesehen, dass LAN natürlich getestet werden muss:
Der Unterschied liegt in einem Bereich, wo ich nicht von 28% sprechen würde. Das ist eher eine Messungenauigkeit bzw. der üblichen Lastfluktioation in Netzwerkgeräten unterworfen.

Wenn aber zum ersten Hop schon 7ms existieren, dann tauchen die auch in allen weiteren Hops wieder auf. Und das ist schon der halbe Unterschied zwischen 15 und 30, den der TE sieht.

 

[johnripper]

(9-7)/7=~0.2857.
Ich also schon.

P.s in 2/3 der Fälle sind es übrigens 9ms. Die 7ms sind nocht geschönt.

Gesendet von meinem SM-G935F mit Tapatalk

 

[Sascha53721]

Ob man 7, 9 15 oder 20ms Ping hat merkt man nirgends wenn es nicht dabei steht. Ab 35/50 ms und höher fängt es an in shooter spürbar zu werden.

Gesendet von meinem HUAWEI NXT-L29 mit Tapatalk

 

[Dragon]

UM-Netz verlassen ist eh falsch ausgedürckt, sagen wir ins Liberty Global Routing einsteigen.
Ich geh einfach mal davon aus, dass Liberty Global (aorta.net) seine Hostnames nicht aus Spaß und Langeweile nach deutschen Städten wählt...
und wenn ich üblich erstmal REU STR und dann FRA habe und dann auf einmal KOB STR FRA scheint sich was an dem Einstiegspunkt geändert zu haben :>

Kannst du mal einen traceroute erstellen, wo man das sieht? Hier in Karlsruhe ist nämlich gar nichts zu erkennen. Nach nichtssagenden IP-Adressen (kein Hostname oder private Ranges) ist man auf einmal in Frankfurt.
Bist du sicher, dass es KOB war, so ein Netzknoten kenne ich gar nicht?

 

[addicted]

(9-7)/7=~0.2857.

Mir gings nicht um die Zahl 28, sondern darum, den 2ms überhaupt eine Bedeutung zuzumessen.
Das ist so wenig Zeit (insb. wenn man berücksichtigt, dass da WLAN passiert), dass ich das völlig ignorieren würde.

Das Beispiel hier verdeutlicht ganz gut, wieso ich das so sehe:

$ ping -c4 172.23.55.212
PING 172.23.55.212 (172.23.55.212) 56(84) bytes of data.
64 bytes from 172.23.55.212: icmp_seq=1 ttl=64 time=78.5 ms
64 bytes from 172.23.55.212: icmp_seq=2 ttl=64 time=1.21 ms
64 bytes from 172.23.55.212: icmp_seq=3 ttl=64 time=1.37 ms
64 bytes from 172.23.55.212: icmp_seq=4 ttl=64 time=4.18 ms

Das erste Paket kommt oft etwas später, zum Beispiel weil die Verbindung unbekannt ist und er daher den langen Weg durch den Connection Tracking Code läuft. Das ist halt ein Ausreisser, den beachten wir nicht weiter.
Pingziel ist ein Smartphone in meinem WLAN, Quellrechner ist per LAN verbunden. Man sieht eine Varianz von fast 3ms zwischen dem kleinsten und dem größten Wert. Auf dem Netz und beiden Geräten ist keine Vordergrundaktivität.

 

[tq1199]

..., wo man das sieht? Hier in Karlsruhe ist nämlich gar nichts zu erkennen. Nach nichtssagenden IP-Adressen (kein Hostname oder private Ranges) ist man auf einmal in Frankfurt.

Z. B.:

<i>
</i>:~ $ mtr -4r -i 2 -c 2 heise.de
Start: Fri Jun 2 21:42:44 2017
HOST: xxxxxxxxxxx Loss% Snt Last Avg Best Wrst StDev 1.|-- fritz.box 0.0% 2 5.6 7.0 5.6 8.5 2.0 2.|-- HSI-KBW-3#-##-##-#.hsi14. 0.0% 2 15.2 14.8 14.3 15.2 0.0 3.|-- 172.30.10.69 0.0% 2 15.1 15.2 15.1 15.2 0.0 4.|-- de-str01c-rc1-ae11-0.aort 0.0% 2 24.4 20.7 17.0 24.4 5.2 5.|-- de-fra04a-rc1-ae29-0.aort 0.0% 2 22.3 24.7 22.3 27.1 3.3 6.|-- de-fra01b-ri1-ae1-0.aorta 0.0% 2 20.0 20.6 20.0 21.2 0.0 7.|-- te0-0-2-3.c150.f.de.plusl 0.0% 2 18.2 17.8 17.4 18.2 0.0 8.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0 9.|-- 212.19.61.13 0.0% 2 24.1 21.4 18.8 24.1 3.7 10.|-- redirector.heise.de 0.0% 2 18.6 19.1 18.6 19.6 0.0

<i>
</i>:~ $ dig -x 84.116.190.129 +short
de-str01c-rc1-ae11-0.aorta.net.
:~ $ dig -x 84.116.140.205 +short
de-fra04a-rc1-ae29-0.aorta.net.
:~ $ dig -x 84.116.134.10 +short
de-fra01b-ri1-ae1-0.aorta.net.

<i>
</i>:~ $ geoiplookup 84.116.190.129
GeoIP Country Edition: AT, Austria
:~ $ geoiplookup 84.116.140.205
GeoIP Country Edition: AT, Austria
:~ $ geoiplookup 84.116.134.10
GeoIP Country Edition: AT, Austria

EDIT:

Ja, das stimmt schon, denn je nach Anschluss kann man nach der privaten IP-Adresse (172.30.10.117) auch direkt in "Frankfurt" sein. Z. B. (ohne den Zwangs-Router von UM, d. h. direkt am Kabel-Modem):

<i>
</i>:~ $ mtr -4nr -c 2 -i 2 193.99.144.80
Start: Fri Jun 2 22:17:52 2017
HOST: yyyyyy Loss% Snt Last Avg Best Wrst StDev 1.|-- 37.##.##.# 0.0% 2 8.7 10.8 8.7 12.9 2.8 2.|-- 172.30.10.117 0.0% 2 8.5 10.6 8.5 12.6 2.8 3.|-- 84.116.190.21 0.0% 2 25.0 18.7 12.4 25.0 8.8 4.|-- 84.116.134.6 0.0% 2 13.6 15.5 13.6 17.3 2.4 5.|-- 80.81.192.132 0.0% 2 15.1 13.5 12.0 15.1 2.0 6.|-- ??? 100.0 2 0.0 0.0 0.0 0.0 0.0 7.|-- 212.19.61.13 0.0% 2 11.1 11.3 11.1 11.4 0.0 8.|-- 193.99.144.80 0.0% 2 13.1 14.7 13.1 16.3 2.2

<i>
</i>:~ $ dig -x 84.116.190.21 +short
de-fra01b-rc1-ae33-0.aorta.net.
:~ $ dig -x 84.116.134.6 +short
de-fra01b-ri1-ae0-0.aorta.net.

 

[Dragon]

Genau, das meinte ich. Entweder "direkt" Frankfurt oder über Stuttgart. Was anderes habe ich beim Aorta noch nicht gesehen. Selbst zu KabelBW-Zeiten gab es meines Wissens nur STU, KAE und SIN, sowie die Übergabepunkte in FRA und MUC. Die Netzknoten selbst waren allerdings nicht sichtbar.
Aber laut Gizeh775 scheint es noch mehr Hostnames zu geben...

 

[rv112]

Hier mal eine trace von einem reinen IPv4 Anschluss mit Modem:

Routenverfolgung zu heise.de [193.99.144.80]
über maximal 30 Hops: 1 <1 ms <1 ms <1 ms pfsense [192.168.1.1] 2 8 ms 6 ms 7 ms HSI-KBW-xxx-49-100-1.hsi14.kabel-badenwuerttemberg.de [xxx.49.100.1] 3 7 ms 7 ms 11 ms 172.30.22.57 4 36 ms 29 ms 30 ms de-fra04a-rc1-ae60-0.aorta.net [84.116.191.29] 5 8 ms 9 ms 8 ms de-fra01b-ri1-ae1-0.aorta.net [84.116.134.10] 6 11 ms 9 ms 15 ms te0-0-2-3.c150.f.de.plusline.net [80.81.192.132] 7 * * * Zeitüberschreitung der Anforderung. 8 8 ms 8 ms 9 ms 212.19.61.13 9 10 ms 9 ms 8 ms redirector.heise.de [193.99.144.80]
Ablaufverfolgung beendet.