Hallo Stosi,

danke sehr für Ihre Hinweise, auf die ich gern eingehe:

Nur weil meine T-Com Leitung kaum Interleaving hat und recht schnell ist (Dank eines guten - nicht T-Com Modems und Routers), heißt es noch lange nicht, dass die anderen schlechter sind.

immerhin heißt es aber doch, dass die Telekom-Leitung sich nicht vor den Wettbewerbern zu verstecken braucht - auch nicht im Hinblick auf die Latenzen jenseits Ihres DSL-Ports? (tu)

Zumal die Routen bei allen anderen Providern besser sind, einige ein Interleaving von 20ms haben oder entsprechende "Provider Router", die mal eben 8ms-10ms Latenz einbauen.

aber das hieße ja, dass die "Provider Router" der Telekom (vermutlich meinen Sie die "internen" Routen im DTAG -Backbone?) "besser" konfiguriert sind als die der Wettbewerber (mit den eingebauten 10 msec Latenz)? . . .

Dies ist auch logisch, da es nur ein "Ping" zu den Gameservern bei Bioware ist. Dazu habe ich ein Bild eines Pingplotter Logs gepostet.

danke schön für Ihren Hinweis - und diese PingPlotter-Grafik belegt eindeutig, dass die Latenzen *nicht* im Netz der DTAG entstehen . . . sondern bei unserem Transport-Partner, mit dem wir eh bereits Verhandlungen führen . . .


beste Grüße
von
Helge.

Hallo A.Breck,

danke sehr für Ihre Rückfragen:

Aber Ihre Annahme das es schon bei HOP2 losgeht also meinen Einwahlknoten / DSLAM kann ich da nicht ganz nachvollziehen. Denn wenn es das wirklich wäre, wieso sind denn da dann die Pingzeiten normal (40-50) und erst viel später werden die Pingzeiten unerträglich, wie das der Heutige Tracert mehr als deutlich zeigt.

entscheidend für die Frage "wie gut ist die Verbindung zu meinem Ziel im Internet?" ist nicht die jeweilige Dauer bis zur Rückmeldung eines der dazwischenliegenden Hops, sondern die Dauer bis zur Rückmeldung des *Zieles*.

Diese Dauer wiederum umfasst nicht allein die Laufzeit auf dem Hinweg, sondern auch die auf dem Rückweg - gerade dieser Rückweg aber ist in einem Tracelog, Pingplot u. ä. *nicht* dokumentiert und bleibt völlig "im Dunkeln".

Wenn nun die Gesamtlaufzeit für den Ping auf l2authd.lineage2.com (Ziel-Hop 10) "nur" gute 80 msec beträgt, die (zu vermutende) Laufzeit für den Ping auf den Hop 2 bereits 40 msec, trägt dieser erste Hop bereits die Hälfte zur Gesamtlaufzeit bei.

Wirklich *kritikabel* finde ich in der Tat weder den einen (80 msec) noch den anderen (40 msec) Wert . . .

Also ich seh den 2 HOP mit den 41ping als nicht Problematisch,

dito . . .

was hingegen direkt auffällt ist Übergang von HOP4 zu HOP5. Wie erklären Sie denn das nun bitte?

wie bereits mehrfach erläutert: mit der Konfiguration des betreffenden Servers, der Ping-Pakete nachrangig abarbeitet.


beste Grüße
von
Helge.

Hallo Stosi, ... ... Dies ist auch logisch, da es nur ein "Ping" zu den Gameservern bei Bioware ist. Dazu habe ich ein Bild eines Pingplotter Logs gepostet.

danke schön für Ihren Hinweis - und diese PingPlotter-Grafik belegt eindeutig, dass die Latenzen *nicht* im Netz der DTAG entstehen . . . sondern bei unserem Transport-Partner, mit dem wir eh bereits Verhandlungen führen . . .


beste Grüße
von
Helge.

Erm wie bitte ??

Man sieht also "keine" Latenzsprünge am Hop "62.157.249.78" ?
Und dieser Knoten "62.157.249.78" gehört nicht der T-Com ?

Wenn ICMP "nur" niedrige Priorität besitzt, deutet dies immer noch auf "Last Spitzen" alle 70/75 Sekunden hin. Werden in diesem Zeitraum ja Ressourcen für wichtigeres als ICMP genutzt...

Network information for 62.157.249.78
IP Address: 62.157.249.78
Current RDNS: No Reverse DNS
CIDR mask: 62.156.0.0/14
Originating from AS: AS3320
Governing registry: ripencc
Allocated on:
Owned by: DTAG Deutsche Telekom AG
Country: Country: Germany (DE)

Ist im Übrigen GENAU der selbe "Bekannte" der auch in "meiner" Verbindung für Probleme sorgt.

http://s7.directupload.net/images/140227/k9bkpxn6.jpg

Bis zum heutigen Tag hat sich daran auch nichts geändert.

Im Übrigen erschließt sich mir nicht warum von Seiten der T-Com immer wieder auf "Dritte" hingewiesen wird.
ICH habe einen Vertrag über die Gestellung eines Internet Anschlusses mit der T-Com.
ICH kann mich nicht erinnern je gelesen zu haben, das mein Vertrag NUR einen Anschluss an das T-Com eigene Netz beinhaltet.
Wenn die T-Com Peering Verträge mit Level3, Telia oder anderen Carriern abschließt, ist dies kein Problem des Kunden.
Der T-Com steht es frei mit anderen Tier1 Netz Betreibern Verträge abzuschließen.
Zumal (siehe Historie nur in diesem Threat) Probleme ähnlicher/gleicher Art lange, sehr lange bekannt sind.

mfg

Hallo!

Zumal die Routen bei allen anderen Providern besser sind, einige ein Interleaving von 20ms haben oder entsprechende "Provider Router", die mal eben 8ms-10ms Latenz einbauen.

aber das hieße ja, dass die "Provider Router" der Telekom (vermutlich meinen Sie die "internen" Routen im DTAG -Backbone?) "besser" konfiguriert sind als die der Wettbewerber (mit den eingebauten 10 msec Latenz)? . . .


Na wenn ich mir so den 2. und 3. Hop ansehe und dort schon 20ms - 30ms sind,
ist es entweder das Interleaving, ein "schlechter" Router oder das Modem des Nutzers.
Wenn ich ein Modem mit Broadcom-Chip nehme, dann habe ich auch 5ms mehr Latenz zum 2. Hop.

Dies ist auch logisch, da es nur ein "Ping" zu den Gameservern bei Bioware ist. Dazu habe ich ein Bild eines Pingplotter Logs gepostet.

danke schön für Ihren Hinweis - und diese PingPlotter-Grafik belegt eindeutig, dass die Latenzen *nicht* im Netz der DTAG entstehen . . . sondern bei unserem Transport-Partner, mit dem wir eh bereits Verhandlungen führen . . .


Wenn ich mir den Hop mit der IP 62.157.249.78 ansehe, der natürlich nur auf die ICMP-Pakete so schlecht anwortet ;), da könnte man schon etwas anderes vermuten. Vorallem, da es ja nur alle 70 Sekunden "schlecht" ist und nicht generell.
Ob die T-Com Probleme hat oder der Transport-Partner, das ist mir ziemlich egal. Eines ist aber klar, auf der Route stimmt etwas nicht und der Ansprechpartner für mich ist und bleibt die Telekom, denn die hat die Route verhandelt.
Sollte die Telekom außerstande sein die Route an die geänderten Nutzerverhalten anzugleichen, dann muß der User eben in den sauren Apfel beissen und zu einem anderen Backbonebetreiber wechseln.

Hallo!

Herrlich... mal ein Traceroute über T-Com Looking Glass abgesetzt.
Selbst dann werden mal eben 40ms beim 62.157.249.78 raufgehauen.

traceroute to 159.153.34.41 (159.153.34.41), 20 hops max, 60 byte packets
1 HH-EB1.HH.DE.net. DTAG .DE (194.25.0.213) 6.044 ms 6.025 ms 6.010 ms
2 hh-eb5-i.HH.DE.NET. DTAG .DE (62.154.32.118) 4.043 ms 4.050 ms 4.042 ms
3 62.157.249.78 (62.157.249.78) 44.833 ms 44.823 ms 44.810 ms
4 ae-11-11.car1.Hamburg1.Level3.net (4.69.133.177) 30.197 ms 30.183 ms 30.171 ms
5 ae-4-4.ebr1.Dusseldorf1.Level3.net (4.69.133.182) 29.486 ms 29.473 ms 29.460 ms
6 ae-23-23.ebr2.Dusseldorf1.Level3.net (4.69.143.190) 28.633 ms ae-21-21.ebr2.Dusseldorf1.Level3.net (4.69.143.182) 29.494 ms ae-23-23.ebr2.Dusseldorf1.Level3.net (4.69.143.190) 28.605 ms
7 ae-47-47.ebr1.Amsterdam1.Level3.net (4.69.143.205) 29.440 ms ae-48-48.ebr1.Amsterdam1.Level3.net (4.69.143.209) 29.458 ms 29.447 ms
8 ae-43-43.ebr2.London15.Level3.net (4.69.167.41) 28.651 ms ae-42-42.ebr2.London15.Level3.net (4.69.167.37) 29.499 ms ae-43-43.ebr2.London15.Level3.net (4.69.167.41) 28.627 ms
9 ae-5-5.car1.Dublin1.Level3.net (4.69.136.89) 127.619 ms 127.618 ms 127.610 ms
10 213.242.106.234 (213.242.106.234) 28.334 ms 28.319 ms 28.579 ms
11 159.153.72.14 (159.153.72.14) 32.690 ms 159.153.72.22 (159.153.72.22) 32.189 ms 31.866 ms
12 159.153.34.41 (159.153.34.41) 31.854 ms 31.849 ms 31.950 ms

Eines ist aber klar, auf der Route stimmt etwas nicht und der Ansprechpartner für mich ist und bleibt die Telekom, denn die hat die Route verhandelt. Sollte die Telekom außerstande sein die Route an die geänderten Nutzerverhalten anzugleichen, dann muß der User eben in den sauren Apfel beissen und zu einem anderen Backbonebetreiber wechseln.

Falsch ... der Contentanbieter bzw. dessen Provider sucht den Peering -Provider raus.
Je nachdem wie viel Geld da verwendet wird, werden Routen ausgesucht.

Man kann einfach eine andere AS verwenden aber da dies kostet mehr Geld.
Jedoch hat da die Telekom eher wenig mit zutun, die kann nur die Anfragen an den Peering -Provider weiterreichen.

Eines ist aber klar, auf der Route stimmt etwas nicht und der Ansprechpartner für mich ist und bleibt die Telekom, denn die hat die Route verhandelt. Sollte die Telekom außerstande sein die Route an die geänderten Nutzerverhalten anzugleichen, dann muß der User eben in den sauren Apfel beissen und zu einem anderen Backbonebetreiber wechseln.

Falsch ... der Contentanbieter bzw. dessen Provider sucht den Peering -Provider raus.
Je nachdem wie viel Geld da verwendet wird, werden Routen ausgesucht.

Man kann einfach eine andere AS verwenden aber da dies kostet mehr Geld.
Jedoch hat da die Telekom eher wenig mit zutun, die kann nur die Anfragen an den Peering -Provider weiterreichen.

Ja neee!

Peeringpartner der Telekom ist nunmal Level 3 und nicht der Contentanbieter. Andere Anbieter in DE haben weniger Probleme mit Level 3 und andere (bessere) Routen.
Ausserdem wird ja schon mit Level 3 verhandelt um der Telekom eine bessere Route zu besorgen.

Die Telekom kann ja mal bei EA anklopfen, ob ein Peering gewünscht ist inkl. neuer Leitung nach Irland...

Und EA hat da auch seinen eigenen AS: AS57052

Im Übrigen erschließt sich mir nicht warum von Seiten der T-Com immer wieder auf "Dritte" hingewiesen wird. ICH habe einen Vertrag über die Gestellung eines Internet Anschlusses mit der T-Com. ICH kann mich nicht erinnern je gelesen zu haben, das mein Vertrag NUR einen Anschluss an das T-Com eigene Netz beinhaltet. Wenn die T-Com Peering Verträge mit Level3, Telia oder anderen Carriern abschließt, ist dies kein Problem des Kunden. Der T-Com steht es frei mit anderen Tier1 Netz Betreibern Verträge abzuschließen. Zumal (siehe Historie nur in diesem Threat) Probleme ähnlicher/gleicher Art lange, sehr lange bekannt sind. mfg

Wow, du kennst dich mit Verträgen scheibar richtig gut aus. Schreib mir doch mal kurz die Stelle raus, wo dir eine bestimmte Latenz / Antwortzeit in alle Ecken des Internets zugesichert wird.

Herrlich... mal ein Traceroute über T-Com Looking Glass abgesetzt. Selbst dann werden mal eben 40ms beim 62.157.249.78 raufgehauen. traceroute to 159.153.34.41 (159.153.34.41), 20 hops max, 60 byte packets ... 3 62.157.249.78 (62.157.249.78) 44.833 ms 44.823 ms 44.810 ms

Ach?

9 ae-5-5.car1.Dublin1.Level3.net (4.69.136.89) 127.619 ms 127.618 ms 127.610 ms

Und dann erst der 4.69.136.89, der "haut nochmal eben 127 ms" drauf!

Sauerei!

12 159.153.34.41 (159.153.34.41) 31.854 ms 31.849 ms 31.950 ms

Wie passen die Antwortzeiten zum Zielserver von 31.8ms eigentlich
zu der Theorie, dass beim 62.157.249.78 "mal eben 40ms raufgehauen" werden?

Wie passen die Antwortzeiten zum Zielserver von 31.8ms eigentlich zu der Theorie, dass beim 62.157.249.78 "mal eben 40ms raufgehauen" werden?

Ganz einfach, Probleme mit der Latenz sind ca. alle 70 Sekunden zum Zielserver, nicht konstant und die drei Hops haben als einzige eine extreme Latenz beim absetzen eines Traceroutes oder Pathpings. Ich persönlich habe leider keinen Zugriff auf die Maschinen, also reine Vermutung meinerseits.

Traceroutes und Pings zum Zielserver decken sich aber zeitlich.