Warum O2
Warenkorb
 Service
Gelöst

PPOE Einwahl über Hamburg obwohl Wohnort in NRW

S
Rang

Moin,

seit letzter Woche bin ich o2 Home L Kunde mit einem Bitstream Anschluss (@s93bbi-o2.de)
der über die Telekom bereit gestellt wird.  Die Verbindung vom Draytek Vigor 165 zum MSAN bzw. DSLAM ist sehr gut.

 

Der Gründe für den Wechsel von VF zu o2 waren vor allem, Dual Stack, kein Shared Medium sowie bessere Latenzen für Zeitsensitive Anwendungen.

 

Nach kurzer Zeit ist mir aufgefallen, das meine kompletter Traffic, obwohl ich quasi in der Mitte von NRW wohne (Münster), über die PPOE Verbindung erst einmal nach Hamburg geht und dann erst in die weite Welt. Wäre ja kein Problem wenn dadurch die Latenzen nicht leiden würden. 

Hier mal die Routenverfolgung:

Routenverfolgung zu "heise.de" [193.99.144.80]
über maximal 30 Hops:
  0  DESKTOP-PC.lan [192.168.2.12]
  1  router.lan [192.168.2.1]
  2  loopback1.0001.acln.01.ham.de.net.telefonica.de [62.52.200.147]
  3  bundle-ether27.0006.dbrx.01.ham.de.net.telefonica.de [62.53.12.14]
  4  ae5-0.0001.corx.06.ham.de.net.telefonica.de [62.53.14.232]
  5  ae6-0.0002.corx.02.fra.de.net.telefonica.de [62.53.0.49]
  6  bundle-ether2.0002.dbrx.01.off.de.net.telefonica.de [62.53.0.209]
  7  bundle-ether2.0002.prrx.01.off.de.net.telefonica.de [62.53.28.179]
  8  ipv4.de-cix.fra.de.as12306.plusline.net [80.81.192.132]
  9  82.98.102.7
 10  82.98.102.23
 11  212.19.61.13
 12  redirector.heise.de [193.99.144.80]

 

Jetzt zu meiner eigentlichen Frage:

Ist es möglich das mein PPOE Einwahl Punkt auf Düsseldorf umgestellt wird?
Düsseldorf ist Luftline 100 km entfernt und Hamburg mehr als doppelt so weit (240km) entfernt.

Es wäre einfach schade Geographisch halbwegs nah an den großen Peers in Düsseldorf und Frankfurt zu sitzen und trotzdem schlechtere Latenzen als Leute aus z.B. Hamburg zu haben. Der Weg hin muss ja schlussendlich auch zurück gehen und somit liegen wir bei ungefähr 400 - 500 km Umweg, den mein Traffic machen muss.

 

@o2 Falls eine Umstellung möglich ist stellt mich gerne sofort auf Düsseldorf um.

Ich weiß aus alten Foreneinträgen das es wohl bei o2 früher auch der Normalzustand war das der Traffic aus Münster über das nahe Düsseldorf geschickt wurde / wird?

 

Viele Grüße Stroker

Edit o2_Larissa: Verschoben zu o2 DSL: Router, Software, Internet & Telefonie

icon

Lösung von Stroker 29 November 2021, 10:42

Zur Antwort springen

17 Antworten

o2_Giulia

Hallo @Stroker,

herzlich willkommen in unserer o2 Community :relaxed:

Über welchen Einwahlknoten dein Traffic geroutet wird, lässt sich durch uns leider nicht beeinflussen. Je nach Auslastung kann sich das ja auch ändern. Bemerkst du denn Einschränkungen, ist dein Ping z.B. zu hoch?

Viele Grüße

Giulia

Du willst keine spannenden Neuigkeiten verpassen? Dann abonniere gleich unsere o2 News: https://hilfe.o2online.de/o2-news-3
S
Rang

Moin  @o2_Giulia , 

Der Ping zum ersten Gateway liegt meist bei 13-15 ms. Bei einem Telekomanschluss haben wir hier meistens maximal 4-5 ms. Und diese grundlegende Latenz kommt überall drauf. Im Vergleich bei heise.de z.B habe ich 20 ms- bis zu 25 ms bei o2 und bei der Telekom hat man eben einen Ping von 10 ms (also gut die Hälfte!), da dort das Gateway für die Einwahl geographisch viel näher liegt.  (in Münster) Ich muss sagen ich find es etwas schade das der Ping quasi künstlich so hoch gehalten wird.  Aber auch zwischen den Gateways gibt in Hamburg gib es teilweise Differenzen von bis zu 5 ms. (Nachts ausprobiert). Ich muss sagen bzgl. der Latenz hätte ich mir da etwas mehr erhofft. 

 

Auch eine VPN verbessert das Routing leider nicht, da die Grundlegende Latenz von 13-15 ms auch hier immer drauf kommt. 

Lil.Biene
Rang
Benutzerebene 6

@Stroker

Warum man dich bei O2 Gateway Technisch von Münster aus über Hamburg schickt ist mir auch schleierhaft aber evtl. geschieht das (aktuell) aufgrund einer Lastverteilung...

In Münster wärst du wahrscheinlich bei 1&1 mit Versatel Routing (was die Laufzeiten angeht) besser dran, da Versatel vor Jahren den örtlichen ISP (CityNet?) aufgekauft hat und seitdem auch deren Infrastruktur in Münster für das Routing nutzt. Soweit ich weiß steht in Münster auch ein Versatel-BNG.

Allgemein behaupte ich das sich die Laufzeiten bei O2 in den letzten 2 Jahren eher negativ entwickelt haben bzw. je nach pppoe-connect auffällig schwanken. Mein Routing läuft z.B. über Düsseldorf und je nach pppoe-connect liegt meine Latenz zu heise.de zwischen 13-19ms, wobei da in meinem Fall auch noch ~3ms aufgrund der Kombination meines Broadcom Modem und der LC oben drauf kommen. D.h. im Optimalfall komme ich auf ~13ms nach heise.de/Frankfurt und ohne Modem mit Broadcom xDSL Chipsatz liege ich bei ~10ms. Leider sind es heutzutage aber in der Regel 18-19ms (je nach pppoe-connect)!

Das mit der ~5ms Schwankung kann ich daher bestätigen und ich würde mal darauf tippen das hier irgendwas bei O2 suboptimal läuft bzw. eingestellt ist. Diese 5ms Schwankung betrifft übrigens alle Ziele, also nicht nur Ziele in Frankfurt oder Düsseldorf…

 

Bsp.: heise.de:

 Host                                                                                                                                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. loopback1.0002.acln.02.dus.de.net.telefonica.de                                                                                                                      0.0%    10   14.4  28.1  10.3 100.3  27.9
 2. ae19-0.0001.dbrx.02.dus.de.net.telefonica.de                                                                                                                         0.0%    10   10.4  11.0  10.2  13.6   1.3
 3. ae1-0.0002.corx.01.dus.de.net.telefonica.de                                                                                                                          0.0%    10   18.3  19.0  18.1  21.9   1.3
 4. ae5-0.0001.corx.01.off.de.net.telefonica.de                                                                                                                          0.0%    10   18.2  18.9  18.1  23.6   1.7
 5. bundle-ether2.0003.dbrx.02.fra.de.net.telefonica.de                                                                                                                  0.0%    10   19.0  18.7  18.5  19.1   0.2
 6. bundle-ether1.0005.prrx.02.fra.de.net.telefonica.de                                                                                                                  0.0%    10   15.9  16.2  15.9  16.7   0.3
 7. ipv4.de-cix.fra.de.as12306.plusline.net                                                                                                                              0.0%    10   17.0  18.7  16.9  21.5   1.6
 8. 82.98.102.5                                                                                                                                                          0.0%    10   19.2  19.1  18.9  19.5   0.2
 9. 82.98.102.65                                                                                                                                                         0.0%    10   16.6  16.8  16.5  17.7   0.4
10. 212.19.61.13                                                                                                                                                         0.0%    10   18.3  32.2  16.3 172.0  49.1
11. redirector.heise.de                                                                                                                                                  0.0%    10   18.8  19.0  18.7  19.3   0.2

 

1 Min später nach pppoe reconnect:

 Host                                                                                                                                                                   Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. loopback1.0004.acln.02.dus.de.net.telefonica.de                                                                                                                      0.0%    20   31.7  20.9  10.8  49.0  12.9
 2. ae17-0.0002.dbrx.02.dus.de.net.telefonica.de                                                                                                                         0.0%    20   11.1  11.9  10.6  18.6   2.1
 3. ae3-0.0002.corx.02.dus.de.net.telefonica.de                                                                                                                          0.0%    19   14.0  15.4  14.0  20.8   1.8
 4. ae5-0.0002.corx.02.fra.de.net.telefonica.de                                                                                                                          0.0%    19   14.0  15.1  13.6  24.9   2.6
 5. bundle-ether1.0003.dbrx.02.fra.de.net.telefonica.de                                                                                                                  0.0%    19   14.1  14.4  14.0  15.1   0.2
 6. bundle-ether1.0005.prrx.02.fra.de.net.telefonica.de                                                                                                                  0.0%    19   16.5  16.6  16.3  17.2   0.2
 7. ipv4.de-cix.fra.de.as12306.plusline.net                                                                                                                              0.0%    19   16.7  16.2  14.5  19.6   1.5
 8. 82.98.102.5                                                                                                                                                          0.0%    19   14.7  14.8  14.4  15.1   0.2
 9. 82.98.102.65                                                                                                                                                         0.0%    19   14.4  14.4  13.9  15.1   0.3
10. 212.19.61.13                                                                                                                                                         0.0%    19   14.5  15.9  14.0  41.6   6.2
11. redirector.heise.de                                                                                                                                                  0.0%    19   14.5  14.5  14.2  15.0   0.2

 

S
Rang

@Lil.Biene 

Tja, hätte ich das mit 1&1 mal vorher gewusst. Gegen 1&1 hatte ich mich entschieden, da die Standardmäßig kein Dual-Stack mehr aktiveren sondern nur Dual-Stack Lite.

13ms bis 19ms es wären ja schonmal besser als Minimum 20 ms. Aus welcher Gegend kommst du den? Bzw. wie weit bist du Luftlinie von Düsseldorf entfernt?

Der Punkt mit den 3 ms zusätzliche Latenz bei nem Broadcom Chipsatz ist interessant. Mein Draytek Vigor 165 hat ja soweit ich weiß auch nen Broadcom Chipsatz drin. Aber meine Gegenstelle ist hier auch Broadcom.. Weißt du zufällig ob dann diese 3 ms auch entstehen? Bzw. von welchem Hersteller ist deine Gegenstelle?
Ich dachte da eigentlich dass das ne gute Kombination ist.
Oder können die 3ms +  am VLAN Tagging liegen? Habe mal gelesen, das es da ggf. unterschiede geben kann...

Als Router nutze ich aktuell OpenWrt und lasse darüber das VLAN-Tagging machen und nicht über den Draytek selbst. Hatte ich aber auch mal ausprobiert aber keine Differenz bei der Latenz beobachten können. 

 

Bzgl. der unterschiedlichen Güte der Gateways hatte ich schonmal überlegt ob man da nicht einfach ne Skript schreibt das dann mehrere Reconnects macht bis die PPOE Verbindung auf einem Gateway mit einer halbwegs guten Latenz ist. Ist aber bis jetzt auch nur eine Idee…

 

Und danke erstmal für deinen tollen Beitrag:)

 

 

Lil.Biene
Rang
Benutzerebene 6

Bzw. wie weit bist du Luftlinie von Düsseldorf entfernt?

Sind bei mir ~32km Luftlinie nach Düsseldorf, bin also recht nach dran… Meine PPPoE session wird von der Telekom auf einem BNG in Essen nach Düsseldorf terminiert. Ohne Broadcom Modem sind es jedenfalls ~6-7ms zum ersten Hop im O2 Netz.

Mein Draytek Vigor 165 hat ja soweit ich weiß auch nen Broadcom Chipsatz drin. Aber meine Gegenstelle ist hier auch Broadcom.. Weißt du zufällig ob dann diese 3 ms auch entstehen? Bzw. von welchem Hersteller ist deine Gegenstelle?
Ich dachte da eigentlich dass das ne gute Kombination ist.

Der Vigor 165 hat keinen Broadcom Chipsatz verbaut, sondern eine xDSL Chipsatz von Intel/MaxLinear. Du solltest von dem Latenzproblem also nicht betroffen sein.

Meine LC besitzt auch einen Chipsatz von Broadcom, denn die Telekom hat bei VDSL ausschließlich LC’s mit Broadcom Chipsatz im Einsatz. Diese +3ms kommen übrigens nur bei älteren LC’s vor. Bei neuen SV-fähigen LC’s gibt es dieses Latenzproblem meines Wissens nicht mehr. Das Problem liegt wohl an dem Zusammenspiel zwischen xDSL Treiber (Modem) und der LC. Die Latenz erhöht sich nach erfolgreichem Sync nach ca. 1-3minuten um ~3ms (je nach xDSL Treiber). Bei meiner LC (sehr altes Model) kommt das Problem z.B. auch mit einem Vigor 130 (Lantiq Chipsatz) vor aber komischerweise tritt das Problem mit einer 7362SL (selber xDSL Chipsatz) je nach Treiber Version nicht auf.

Oder können die 3ms +  am VLAN Tagging liegen? Habe mal gelesen, das es da ggf. unterschiede geben kann...

Nein, es liegt nicht am VLAN Tagging.

Als Router nutze ich aktuell OpenWrt und lasse darüber das VLAN-Tagging machen und nicht über den Draytek selbst.

Gute Wahl, setze doch mal in deiner network Konfig folgendes unter config interface ‘wan’:

option pppd_options 'debug'

Danach machst du ein pppoe-reconnect mit ifup wan und schaust anschließend via logread | grep pppd über welchen BNG du angebunden bist ([AC-name XXXJXX]). Evtl liegt dieser geografisch näher an Hamburg als an Düsseldorf und deshalb findet die Übergabe ins O2 Netz in Hamburg statt. Würde mich zwar wundern wenn die Telekom keinen BNG in Münster oder der näheren Umgebung stehen hat aber man weiß ja nie…

Bzgl. der unterschiedlichen Güte der Gateways hatte ich schonmal überlegt ob man da nicht einfach ne Skript schreibt das dann mehrere Reconnects macht bis die PPOE Verbindung auf einem Gateway mit einer halbwegs guten Latenz ist. Ist aber bis jetzt auch nur eine Idee…

Wäre eine Idee oder O2 schafft endlich mal diese 24h Zwangstrennung ab oder sorgt am besten dafür das die Laufzeiten “im Netz von Telefonica” stabil bleiben und sich nicht nach Lust und Laune um 5ms erhöhen! Bei mir geschieht das mittlerweile sogar innerhalb der selben PPPoE Session im laufenden Betrieb! Das war vor ~1.5 Jahren jedenfalls noch nicht der Fall…

Vor 1.5 Jahren:

Frankfurt:
root@DP-6:~# ping heise.de -c5
PING heise.de (193.99.144.80): 56 data bytes
64 bytes from 193.99.144.80: seq=0 ttl=245 time=9.389 ms
64 bytes from 193.99.144.80: seq=1 ttl=245 time=9.308 ms
64 bytes from 193.99.144.80: seq=2 ttl=245 time=10.150 ms
64 bytes from 193.99.144.80: seq=3 ttl=245 time=9.823 ms
64 bytes from 193.99.144.80: seq=4 ttl=245 time=9.740 ms

Düsseldorf:
PING gamed.de (89.163.236.29): 56 data bytes
64 bytes from 89.163.236.29: seq=0 ttl=58 time=5.675 ms
64 bytes from 89.163.236.29: seq=1 ttl=58 time=6.117 ms
64 bytes from 89.163.236.29: seq=2 ttl=58 time=5.961 ms
64 bytes from 89.163.236.29: seq=3 ttl=58 time=6.200 ms
64 bytes from 89.163.236.29: seq=4 ttl=58 time=6.064 ms

 

Heute:

root@AX-9:~# ping heise.de -c5
PING heise.de (193.99.144.80): 56 data bytes
64 bytes from 193.99.144.80: seq=0 ttl=245 time=17.631 ms
64 bytes from 193.99.144.80: seq=1 ttl=245 time=18.254 ms
64 bytes from 193.99.144.80: seq=2 ttl=245 time=19.865 ms
64 bytes from 193.99.144.80: seq=3 ttl=245 time=17.338 ms
64 bytes from 193.99.144.80: seq=4 ttl=245 time=17.442 ms

PING gamed.de (89.163.236.29): 56 data bytes
64 bytes from 89.163.236.29: seq=0 ttl=58 time=11.017 ms
64 bytes from 89.163.236.29: seq=1 ttl=58 time=11.392 ms
64 bytes from 89.163.236.29: seq=2 ttl=58 time=11.279 ms
64 bytes from 89.163.236.29: seq=3 ttl=58 time=11.201 ms
64 bytes from 89.163.236.29: seq=4 ttl=58 time=11.394 ms

 

S
Rang

@Lil.Biene 

Der Vigor 165 hat keinen Broadcom Chipsatz verbaut, sondern eine xDSL Chipsatz von Intel/MaxLinear. Du solltest von dem Latenzproblem also nicht betroffen sein.

 

Stimmt,da haste recht!  Jetzt wo du es schreibst kommt es mir bekannt vor :)

 

Meine LC besitzt auch einen Chipsatz von Broadcom, denn die Telekom hat bei VDSL ausschließlich LC’s mit Broadcom Chipsatz im Einsatz. Diese +3ms kommen übrigens nur bei älteren LC’s vor. Bei neuen SV-fähigen LC’s gibt es dieses Latenzproblem meines Wissens nicht mehr. Das Problem liegt wohl an dem Zusammenspiel zwischen xDSL Treiber (Modem) und der LC. Die Latenz erhöht sich nach erfolgreichem Sync nach ca. 1-3minuten um ~3ms (je nach xDSL Treiber). Bei meiner LC (sehr altes Model) kommt das Problem z.B. auch mit einem Vigor 130 (Lantiq Chipsatz) vor aber komischerweise tritt das Problem mit einer 7362SL (selber xDSL Chipsatz) je nach Treiber Version nicht auf.

 

Hier gehts im speziellen um 35b oder? Weil bei nem 17a Anschluss kenne ich wen mit Huawei als LC.

LC = Linecard ?(Nur damit wir uns nicht missverstehen ;) )

Danach machst du ein pppoe-reconnect mit ifup wan und schaust anschließend via logread | grep pppd über welchen BNG du angebunden bist ([AC-name XXXJXX]). Evtl liegt dieser geografisch näher an Hamburg als an Düsseldorf und deshalb findet die Übergabe ins O2 Netz in Hamburg statt. Würde mich zwar wundern wenn die Telekom keinen BNG in Münster oder der näheren Umgebung stehen hat aber man weiß ja nie…

Sieht wohl nach Münster aus:

[AC-name MSTJ01]

Kannte das Feature noch nicht das man damit den BNG auslesen kann :)

Wäre eine Idee oder O2 schafft endlich mal diese 24h Zwangstrennung ab oder sorgt am besten dafür das die Laufzeiten “im Netz von Telefonica” stabil bleiben und sich nicht nach Lust und Laune um 5ms erhöhen! Bei mir geschieht das mittlerweile sogar innerhalb der selben PPPoE Session im laufenden Betrieb! Das war vor ~1.5 Jahren jedenfalls noch nicht der Fall…

Mal sehen ob das mal  irgendwann passiert.

Bei mir schauts aktuell so aus (Ping Abfragen direkt über den Router)

PING heise.de (193.99.144.80): 56 data bytes
64 bytes from 193.99.144.80: seq=0 ttl=245 time=19.229 ms
64 bytes from 193.99.144.80: seq=1 ttl=245 time=18.846 ms
64 bytes from 193.99.144.80: seq=2 ttl=245 time=19.378 ms
64 bytes from 193.99.144.80: seq=3 ttl=245 time=19.338 ms
64 bytes from 193.99.144.80: seq=4 ttl=245 time=19.426 ms

Hatte aber im lauf davor nen anderen Gateway und da auch wieder nen 24 ms bis 25 ms Ping.

 

Bei gamed.de habe ich folgenden Ping.. Liegt wohl daran das der Server in Düsseldorf steht..

PING gamed.de (89.163.236.29): 56 data bytes
64 bytes from 89.163.236.29: seq=0 ttl=55 time=20.069 ms
64 bytes from 89.163.236.29: seq=1 ttl=55 time=20.203 ms
64 bytes from 89.163.236.29: seq=2 ttl=55 time=20.009 ms
64 bytes from 89.163.236.29: seq=3 ttl=55 time=20.119 ms
64 bytes from 89.163.236.29: seq=4 ttl=55 time=20.015 ms

 

Lil.Biene
Rang
Benutzerebene 6

Hier gehts im speziellen um 35b oder? Weil bei nem 17a Anschluss kenne ich wen mit Huawei als LC.

LC = Linecard ?(Nur damit wir uns nicht missverstehen 😉 )

LC=Linecard. Über eine SV-fähige LC kann auch ein 17a Profil geschaltet werden, wobei das eher selten passiert bzw nur dann vorkommt wenn ausschließlich SV-LC’s verbaut wurden oder keine Ports mehr auf den anderen non-SV LC’s frei sind. In der Regel sind die SV-LC’s für SV/35b Kunden reserviert...

Den Vigor 165 hatte ich mal für ein paar Tage zum testen hier aber das Gerät hat mich im Vergleich zu meinem Modem mit BCM63138 Chipsatz nicht überzeugt (Fehlerwerte und Upstream Sync bei VDSL100). Wobei ich gelesen habe das der Vigor165 mit aktuellem Modem Code bei Supervectoring sehr gut und stabil laufen soll. Mangels SV/35b konnte ich das damals leider nicht testen...

Bin mir gerade nicht mehr sicher aber ich glaube mit dem Vigor hast du auch die Möglichkeit die Versionsnummer der LC auszulesen. Damit kann man evtl raus finden ob es sich bei dir um eine SV-fähige LC handelt. Das ganze war beim Vigor 165 irgendwo in der ATU-C info via vdsl status zu finden.

Sieht wohl nach Münster aus:

[AC-name MSTJ01]

Ja, ist Münster…

Bei mir schauts aktuell so aus (Ping Abfragen direkt über den Router)

Sieht von Münster ausgehend schon ein wenig Suboptimal aus aber das wird O2 wohl nicht interessieren. Das mit den +5ms ist aber wirklich komisch und dachte bisher das dies nur in meiner Region vorkommt aber anscheinend liegt hier generell ein Problem beim O2/Telefonica Routing vor worauf wir als Endkunden leider null Einfluss haben...

S
Rang

@Lil.Biene 

Hast du mit dem Vigor 165 die Möglichkeit die Versionsnummer der LC auszulesen? Damit kann man evtl rausfinden ob es sich bei dir um eine SV-fähige LC handelt. Bei meinem Vigor 130 war das damals in der ATU-C info via vdsl status zu finden, wobei ich mir da gerade nicht mehr so sicher bin.

Ja, das geht mit dem 165 noch genauso:

  -------------------------------- ATU-C Info ---------------------------------

   Far Current Attenuation :        6 dB    Far SNR Margin       :        9  dB

   CO ITU Version[0]       : b5004244       CO ITU Version[1]    : 434dc01a

   DSLAM CHIPSET VENDOR    : < BDCM >

Weißt du warum es dort die 0 und die 1 gibt?

Lil.Biene
Rang
Benutzerebene 6

Weißt du warum es dort die 0 und die 1 gibt?

Das kann ich dir leider nicht beantworten aber für die Versionsnummer (die z.B. eine Fritzbox ausgibt) sind nur die letzten 2 Bytes (Hexadezimal) vom letzten Wert nötig. Wenn man diesen Wert in Dezimal umrechnet kommt man auf die Versionsnummer. Bsp.: 434d c0 1a = Versionsnummer 192.26

Bei 192.26 ist es schwierig zu sagen ob es sich um eine SV-LC handelt, da bei Huawei die gleiche Versionsnummer auch bei non-SV-LCs vorkommt. Ist SV bei dir Verfügbar?

S
Rang

Bei 192.26 ist es schwierig zu sagen ob es sich um eine SV-LC handelt, da bei Huawei die gleiche Versionsnummer auch bei non-SV-LCs vorkommt. Ist SV bei dir Verfügbar?

Ja, laut Telekom und laut o2 ist bei mir 35b verfügbar.

Können denn unterschiedliche LC’s den Ping verändern? 

Lil.Biene
Rang
Benutzerebene 6

Können denn unterschiedliche LC’s den Ping verändern? 

In Verbindung mit einem Modem mit Broadcom Chipsatz kann das bei älteren LC’s der Fall sein und bei meiner LC kommt das Problem sogar mit einer Fritzbox 7530 @07.27 vor (Intel xDSL Chipsatz). Welche Versionsnummer und/oder Hardware Revisionen da genau von betroffen sind kann ich dir nicht sagen aber Adtran 177.191, 178.5 und 178.18 sind auf jeden Fall davon betroffen und soweit ich weiß haben SV-fähige LC’s dieses Problem nicht (mehr). Da bei mir nach wie vor kein SV verfügbar ist kann ich es leider nicht mit einer SV-LC testen.

Du kannst ja mal testen ob sich die Laufzeiten 1-3 Minuten nach dem DSL Sync ändern… Im Endeffekt sind es auch nur ~3ms, also den meisten Menschen wird das wohl kaum auffallen.

S
Rang

@Lil.Biene 

Habe das mal getestet und ich konnte keinen Unterschied erkennen. Ping ist zu Beginn und nach ein paar Minuten der gleiche.

 

Lil.Biene
Rang
Benutzerebene 6

@Lil.Biene

Habe das mal getestet und ich konnte keinen Unterschied erkennen. Ping ist zu Beginn und nach ein paar Minuten der gleiche.

 


Dann bist du davon zum Glück nicht betroffen…

Kann es kaum erwarten das meine LC irgendwann mal den Geist aufgibt und hier SV-fähige LC’s verbaut werden. Seit einigen Updates ist meine LC merklich schlechter geworden und ich bezweifel auch das dieser Latenzbug jemals bei dieser HW-Revision behoben wird.

Einfach nur ein Trauerspiel (bsp. nach Resync):

PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: seq=0 ttl=58 time=5.040 ms
64 bytes from 1.1.1.1: seq=1 ttl=58 time=5.102 ms
64 bytes from 1.1.1.1: seq=2 ttl=58 time=5.281 ms
64 bytes from 1.1.1.1: seq=3 ttl=58 time=5.199 ms
64 bytes from 1.1.1.1: seq=4 ttl=58 time=5.375 ms
64 bytes from 1.1.1.1: seq=5 ttl=58 time=5.352 ms
64 bytes from 1.1.1.1: seq=6 ttl=58 time=4.996 ms
64 bytes from 1.1.1.1: seq=7 ttl=58 time=5.173 ms
64 bytes from 1.1.1.1: seq=8 ttl=58 time=5.307 ms
64 bytes from 1.1.1.1: seq=9 ttl=58 time=4.997 ms
64 bytes from 1.1.1.1: seq=10 ttl=58 time=5.400 ms
64 bytes from 1.1.1.1: seq=11 ttl=58 time=5.091 ms
64 bytes from 1.1.1.1: seq=12 ttl=58 time=5.550 ms
64 bytes from 1.1.1.1: seq=13 ttl=58 time=5.124 ms
64 bytes from 1.1.1.1: seq=14 ttl=58 time=5.240 ms
64 bytes from 1.1.1.1: seq=15 ttl=58 time=5.627 ms
64 bytes from 1.1.1.1: seq=16 ttl=58 time=5.545 ms
64 bytes from 1.1.1.1: seq=17 ttl=58 time=5.469 ms
64 bytes from 1.1.1.1: seq=18 ttl=58 time=5.866 ms
64 bytes from 1.1.1.1: seq=19 ttl=58 time=5.280 ms
64 bytes from 1.1.1.1: seq=20 ttl=58 time=5.488 ms
64 bytes from 1.1.1.1: seq=21 ttl=58 time=5.352 ms
64 bytes from 1.1.1.1: seq=22 ttl=58 time=5.017 ms
64 bytes from 1.1.1.1: seq=23 ttl=58 time=5.671 ms
64 bytes from 1.1.1.1: seq=24 ttl=58 time=4.845 ms
64 bytes from 1.1.1.1: seq=25 ttl=58 time=5.025 ms
64 bytes from 1.1.1.1: seq=26 ttl=58 time=5.421 ms
64 bytes from 1.1.1.1: seq=27 ttl=58 time=5.101 ms
64 bytes from 1.1.1.1: seq=28 ttl=58 time=5.232 ms
64 bytes from 1.1.1.1: seq=29 ttl=58 time=5.185 ms
64 bytes from 1.1.1.1: seq=30 ttl=58 time=5.335 ms
64 bytes from 1.1.1.1: seq=31 ttl=58 time=5.000 ms
64 bytes from 1.1.1.1: seq=32 ttl=58 time=5.124 ms
64 bytes from 1.1.1.1: seq=33 ttl=58 time=5.309 ms
64 bytes from 1.1.1.1: seq=34 ttl=58 time=5.236 ms
64 bytes from 1.1.1.1: seq=35 ttl=58 time=5.401 ms
64 bytes from 1.1.1.1: seq=36 ttl=58 time=5.576 ms
64 bytes from 1.1.1.1: seq=37 ttl=58 time=5.218 ms
64 bytes from 1.1.1.1: seq=38 ttl=58 time=5.120 ms
64 bytes from 1.1.1.1: seq=39 ttl=58 time=5.272 ms
64 bytes from 1.1.1.1: seq=40 ttl=58 time=5.216 ms
64 bytes from 1.1.1.1: seq=41 ttl=58 time=8.905 ms
64 bytes from 1.1.1.1: seq=42 ttl=58 time=8.326 ms
64 bytes from 1.1.1.1: seq=43 ttl=58 time=7.983 ms
64 bytes from 1.1.1.1: seq=44 ttl=58 time=8.117 ms
64 bytes from 1.1.1.1: seq=45 ttl=58 time=8.298 ms
64 bytes from 1.1.1.1: seq=46 ttl=58 time=8.212 ms
64 bytes from 1.1.1.1: seq=47 ttl=58 time=8.128 ms
64 bytes from 1.1.1.1: seq=48 ttl=58 time=8.336 ms
64 bytes from 1.1.1.1: seq=49 ttl=58 time=7.955 ms
64 bytes from 1.1.1.1: seq=50 ttl=58 time=8.138 ms
64 bytes from 1.1.1.1: seq=51 ttl=58 time=8.302 ms
64 bytes from 1.1.1.1: seq=52 ttl=58 time=7.962 ms
64 bytes from 1.1.1.1: seq=53 ttl=58 time=8.371 ms
64 bytes from 1.1.1.1: seq=54 ttl=58 time=8.029 ms
64 bytes from 1.1.1.1: seq=55 ttl=58 time=10.977 ms
64 bytes from 1.1.1.1: seq=56 ttl=58 time=10.656 ms
64 bytes from 1.1.1.1: seq=57 ttl=58 time=11.028 ms
64 bytes from 1.1.1.1: seq=58 ttl=58 time=10.720 ms
64 bytes from 1.1.1.1: seq=59 ttl=58 time=10.891 ms
64 bytes from 1.1.1.1: seq=60 ttl=58 time=11.050 ms
64 bytes from 1.1.1.1: seq=61 ttl=58 time=10.726 ms
64 bytes from 1.1.1.1: seq=62 ttl=58 time=10.872 ms
64 bytes from 1.1.1.1: seq=63 ttl=58 time=11.281 ms
64 bytes from 1.1.1.1: seq=64 ttl=58 time=12.683 ms
64 bytes from 1.1.1.1: seq=65 ttl=58 time=10.615 ms
64 bytes from 1.1.1.1: seq=66 ttl=58 time=10.945 ms
64 bytes from 1.1.1.1: seq=67 ttl=58 time=10.382 ms
64 bytes from 1.1.1.1: seq=68 ttl=58 time=10.871 ms
64 bytes from 1.1.1.1: seq=69 ttl=58 time=12.358 ms
64 bytes from 1.1.1.1: seq=70 ttl=58 time=10.904 ms
64 bytes from 1.1.1.1: seq=71 ttl=58 time=11.073 ms
64 bytes from 1.1.1.1: seq=72 ttl=58 time=10.495 ms
64 bytes from 1.1.1.1: seq=73 ttl=58 time=10.896 ms
64 bytes from 1.1.1.1: seq=74 ttl=58 time=10.582 ms
64 bytes from 1.1.1.1: seq=75 ttl=58 time=10.453 ms
64 bytes from 1.1.1.1: seq=76 ttl=58 time=11.144 ms
64 bytes from 1.1.1.1: seq=77 ttl=58 time=10.813 ms
64 bytes from 1.1.1.1: seq=78 ttl=58 time=10.703 ms
64 bytes from 1.1.1.1: seq=79 ttl=58 time=10.638 ms
64 bytes from 1.1.1.1: seq=80 ttl=58 time=11.040 ms
64 bytes from 1.1.1.1: seq=81 ttl=58 time=10.968 ms
64 bytes from 1.1.1.1: seq=82 ttl=58 time=11.089 ms
64 bytes from 1.1.1.1: seq=83 ttl=58 time=10.758 ms
^C
--- 1.1.1.1 ping statistics ---
84 packets transmitted, 84 packets received, 0% packet loss
round-trip min/avg/max = 4.845/7.724/12.683 ms

 

S
Rang

@Lil.Biene 

Das ist wirklich ärgerlich. Zumindest kannst du theoretisch einen Ping von 5 ms bekommen..

Ich habe im absoluten Minimum einen Ping von 10.XXX ms meist aber 11 ms oder höher so zu 1.1.1.1 im Hamburg.

Hatte die Tage mal Cloudflare Warp+ ausprobiert aber auch da keine Verbesserung.. (VPN Verbindung direkt in Hamburg) 

Liegt bei mir eben an der PPOE Verbindung nach Hamburg…

 

Hast du den mal nen Draytek Vigor 165 ausprobiert? Da gibts ja jede Menge Firmware Versionen die dann jeweils auch nochmal andere Modem Firmwares mitbringen.. Evtl. gehts damit irgendwie doch?

Welchen Router benutzt eigentlich?

 

Lil.Biene
Rang
Benutzerebene 6

Den Vigor 165 hatte ich schon mal hier aber das mit der Latenz hatte ich damals nicht getestet. Ich nutze ein DGA 4130 mit Broadcom Chipsatz und bin mit dem Gerät, bis auf den Latenzbug in Verbindung mit meiner LC, sehr zufrieden. Die DGA’s sind aber eine sogenannte “Bastellösung” mit einem Modifizierten GUI und root Zugriff, also bei weitem nicht so komfortabel wie z.B. ein Vigor, dafür aber mit weitaus mehr Möglichkeiten ( z.B. VLANs, verschiedene xDSL Treiber, OpenWrt packages).

Liegt bei mir eben an der PPOE Verbindung nach Hamburg…

Ja sowas ist wirklich ultra ärgerlich und leider denke ich auch das man hier ohne Vitamin B wohl nichts machen kann. Und wir reden hier sogar noch über Münster, welches wirklich gut angebunden ist. Macht einfach null Sinn!

S
Rang

UPDATE: Seit dem 28.11.2021 komme ich mit meiner PPOE-Einwahl endlich in Düsseldorf raus.

Die Latenzen haben sich deutlich verbessert!

 

PING heise.de (193.99.144.80): 56 data bytes64 bytes from 193.99.144.80: seq=0 ttl=245 time=10.879 ms64 bytes from 193.99.144.80: seq=1 ttl=245 time=10.934 ms64 bytes from 193.99.144.80: seq=2 ttl=245 time=12.838 ms64 bytes from 193.99.144.80: seq=3 ttl=245 time=11.213 ms64 bytes from 193.99.144.80: seq=4 ttl=245 time=10.924 ms--- heise.de ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max = 10.879/11.357/12.838 ms

 

PING gamed.de (89.163.236.29): 56 data bytes64 bytes from 89.163.236.29: seq=0 ttl=56 time=7.893 ms64 bytes from 89.163.236.29: seq=1 ttl=56 time=7.448 ms64 bytes from 89.163.236.29: seq=2 ttl=56 time=7.187 ms64 bytes from 89.163.236.29: seq=3 ttl=56 time=7.578 ms64 bytes from 89.163.236.29: seq=4 ttl=56 time=7.532 ms--- gamed.de ping statistics ---5 packets transmitted, 5 packets received, 0% packet lossround-trip min/avg/max = 7.187/7.527/7.893 ms

 

Ich hoffe das die Einwahl jetzt in Düsseldorf verbleibt. Bis jetzt bin ich damit sehr zufrieden.

o2_Kurt

Hi @Stroker ,

 

schön, dass es derzeit wieder klappt!

Ich drücke die Daumen für eine längere Einwahl in Düsseldorf :hugging:

Danke für deine Antworten, @Lil.Biene !

Viele Grüße,
Kurt

Signatur :)

Deine Antwort


Allgemeine Nutzungsbedingungen der O₂ Community
© Telefónica Germany GmbH & Co. OHG Telefónica