[mathias]

Hallo,

traceroute/tracert zu und von beiden IPs zum Anschluss, Speedtest im Rescue-Modus (http://demo.ovh.de/view/5025e158d6a2...2216773e79bf/0) und dann Ticket erstellen.

Das Ergebnis von 2 Downloads (beide IPs) sollte natürlich auch nicht fehlen. Idealer Weise per netcat:
1. Serverinstanz vorher auf dem Zielrechner starten: netcat -l -p 7777
2. Transfer vom Quellrechner aus starten: dd if=/dev/zero bs=20M count=1 | nc IP-ZIELRECHNER 7777

Mathias

[LEENOX]

hab 32mbit kabel.

ich krieg von der main ip 3,5mb/s und wenn ich über die failover auf 188.165.25 oder 188.165.20 gehe schwankts zwischen 1mb/s und 1,6mb/s.
und jetzt erzählt uns doch weiterhin es liegt an uns...

LÄCHERLICH!!!

[kikei]

IP des Servers: 188.165.XXX.XX
Server: KS i7-2T

wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
2010-05-24 21:11:05 (5,39 MB/s) - »/dev/null« gespeichert [104857600/104857600]

wget http://speedtest.netcologne.de/test_1gb.bin -O /dev/null
2010-05-24 21:14:26 (10,9 MB/s) - »/dev/null« gespeichert [1073741824/1073741824]

wget http://www.euserv.de/100mb.nul -O /dev/null
2010-05-24 21:16:30 (4,92 MB/s) - »/dev/null« gespeichert [104857600/104857600]

[Gulaschkanone]

also ich hab keine probleme:

wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
100%[======================================>] 104.857.600 4,62M/s in 20s
2010-05-21 06:15:29 (4,92 MB/s) - »/dev/null« gespeichert [104857600/104857600]

wget http://speedtest.netcologne.de/test_1gb.bin -O /dev/null
100%[====================================>] 1.073.741.824 10,9M/s in 93s
2010-05-21 06:15:03 (11,0 MB/s) - »/dev/null« gespeichert [1073741824/1073741824]

wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
100%[======================================>] 104.857.600 8,82M/s in 20s
2010-05-21 06:13:05 (4,99 MB/s) - »/dev/null« gespeichert [104857600/104857600]

[Kampfkatze]

Dann hier mal mein Ergebnis:

wget http://speedtest.netcologne.de/test_1gb.bin -O /dev/null
100%[====================================>] 1.073.741.824 2,86M/s   in 6m 22s

wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
100%[====================================>] 104.857.600 3,97M/s   in 31s

wget http://www.euserv.de/100mb.nul -O /dev/null
100%[====================================>] 104.857.600 2,48M/s   in 41s

Mal ohne Worte.

[F4RR3LL]

....
wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
...
Bei Speedtests zu Anbietern in DE, liefern beide Server fast identische Ergebnisse, daher kann ein Fehler in der Netzwerkkonfiguration ausgeschlossen werden. Die Diskrepanz ist extrem.

Mit meinem 1und1 Server 1,7 MB/s,
mit mit meinem Serverbasar Server 2,20 MB/s,
mit meinem Hetzner Server 1,15 MB/s,
mit meinem Euserv Server 1,16 MB/s,
und zu guter letzt ein OVH Server in Paris 3,69 MB/s

schwankt auch hier merklich und extrem .... aber nen USA Server als Kandidat ist da auch problematisch

[horst]

Habe mal die Datei im ersten Post auch geladen von meinem Server bei H:
wget http://lg.denver.fdcservers.net/100MBtest.zip -O /dev/null
100%[======================================>] 104,857,600 364K/s in 4m 35s
2010-05-20 23:11:15 (372 KB/s) - `/dev/null' saved [104857600/104857600]

Auch schlecht irgendwie, aber mein server hat keine Probleme sonst. Eventuell ist allgemein die Verbindung in die USA schlecht derzeit ?

Mal eben gleich einen Testdatei aus DE geladen:
wget http://speedtest.netcologne.de/test_1gb.bin -O /dev/null
100%[====================================>] 1,073,741,824 11.2M/s in 92s
2010-05-20 23:13:56 (11.2 MB/s) - `/dev/null' saved [1073741824/1073741824]
100 MBit/s am Limit.

horst

[Kampfkatze]

Die meisten Router sind so konfiguriert, dass sie erst die Arbeit erledigen und dann irgendwann auch auf ping-Anfragen antworten. Manche Router antworten auch gar nicht bzw nicht mehr, wenn die Netzwerk-Last X Prozent übersteigt

Genau das ist der Punkt. Dann halten wir mal fest: Die Router vom 91er liefern dauerhaft Antworten auf alle Pakete und dauerhaft bessere Ping-Zeiten. Die Router vom 188er antworten mal schnell, mal langsam und mal überhaupt nicht. Wenn beide Router nun so konfiguriert sind wie du sagst, dass sie unter Last langsamer oder gar nicht mehr Antworten bedeutet dies, dass die Router vom 188er mehr Last verarbeiten müssen als die vom 91er. Oder sie sind falsch konfiguriert. Auf jeden Fall scheint aber der billigere 91er dann im weniger belasteten, ergo im besseren Netzwerk zu stehen als der 188er. Oder die Anbindung von dem Rechenzentrum in dem die 188er stehen ist schlechter als die der 91er. Oder die Router sind billig, falsch konfiguriert, überlastet oder kaputt. Wenn man nun erwartet, dass die Qualität der Dienstleistung von EG->HG aufsteigt, ist dies ein Zustand, der eigentlich nicht sein sollte. Tatsächlich würde man eher erwarten, dass der Traffic sogar nach Serverreihe in gewissen Grenzen priorisiert wird. Warum z.B. liest man davon, dass die HGs "rennen wie Sau"? Bei den MGs passiert anscheinend genau das Gegenteil.
Das Ergebnis bisher also: Kauf einen EG, dann ist das Netz zwar gut aber der Server stürzt dauernd ab. Kauf einen MG und du kriegst ein Scheiß Netz. Da kauf ich dann aber mit Sicherheit keinen HG mehr, weil ich keine Lust mehr auf weitere Überraschungen habe.

[ServerDepp]

Die meisten Router sind so konfiguriert, dass sie erst die Arbeit erledigen und dann irgendwann auch auf ping-Anfragen antworten. Manche Router antworten auch gar nicht bzw nicht mehr, wenn die Netzwerk-Last X Prozent übersteigt

[Kampfkatze]

@ServerDepp
Was passiert denn dann hier?

1  188.165.212.254 (188.165.212.254)  15.024 ms * *
2  20g.fra-5-6k.routers.chtix.eu (213.251.130.78)  8.090 ms * *

1  188.165.212.254 (188.165.212.254)  4.780 ms * *
2  * * *

1  188.165.212.254 (188.165.212.254)  32.191 ms * *
2  * * *

1  188.165.212.254 (188.165.212.254)  0.353 ms * *
2  * * *

[ServerDepp]

6 * * skynet3.web.kundencontroller.de (85.31.185.122) 27.012 ms
6 * skynet3.web.kundencontroller.de (85.31.185.122) 26.947 ms 27.027 ms
5 skynet3.web.kundencontroller.de (85.31.185.122) 27.249 ms 27.258 ms 27.246 ms
6 * skynet3.web.kundencontroller.de (85.31.185.122) 27.132 ms 27.102 ms

Für mich sieht das nach einer Verbindung in schwankender Qualität aus.

Was genau schwankt denn da? Die Unterwegs-Ping-Zeiten sind in Deinem Fall nicht wichtig, da es ja nicht sein kann, dass das Ziel schneller antwortet, als eine der Unterwegsstationen.

[Kampfkatze]

So hier kommen noch einmal einige traceroutes. Alle zum gleichen Ziel, dem Testserver vom Euserv:

traceroute to 85.31.185.122 (85.31.185.122), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  15.024 ms * *
 2  20g.fra-5-6k.routers.chtix.eu (213.251.130.78)  8.090 ms * *
 3  decix1.jena1.as35366.net (80.81.192.188)  34.271 ms * *
 4  * * *
 5  * * *
 6  * * skynet3.web.kundencontroller.de (85.31.185.122)  27.012 ms

traceroute to 85.31.185.122 (85.31.185.122), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  4.780 ms * *
 2  * * *
 3  * * *
 4  hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1)  27.366 ms * *
 5  * * *
 6  * skynet3.web.kundencontroller.de (85.31.185.122)  26.947 ms  27.027 ms

traceroute to 85.31.185.122 (85.31.185.122), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  32.191 ms * *
 2  * * *
 3  decix1.jena1.as35366.net (80.81.192.188)  34.380 ms * *
 4  hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1)  27.467 ms  27.524 ms  27.706 ms
 5  skynet3.web.kundencontroller.de (85.31.185.122)  27.249 ms  27.258 ms  27.246 ms

traceroute to 85.31.185.122 (85.31.185.122), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  0.353 ms * *
 2  * * *
 3  * * *
 4  hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1)  27.529 ms * *
 5  * * *
 6  * skynet3.web.kundencontroller.de (85.31.185.122)  27.132 ms  27.102 ms

Für mich sieht das nach einer Verbindung in schwankender Qualität aus. Der erste Hop antwortet mal mit 0.3ms und mal mit 34ms. Der zweite Hop anwortet überhaupt nur beim ersten Traceroute.

Zum Testserver von fdcserver sieht es so aus:

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  0.317 ms * *
 2  * * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  5.581 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  7.782 ms  7.867 ms  7.863 ms
 5  if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  5.790 ms if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.123 ms if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  5.910 ms
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  96.650 ms  95.981 ms  95.860 ms
 7  63.243.186.66 (63.243.186.66)  96.074 ms *  95.791 ms
 8  Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.790 ms Vlan546.icore1.NTO-NewYork.as6453.net (209.58.26.58)  96.897 ms  96.894 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  81.749 ms  81.771 ms  81.748 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  109.952 ms  109.937 ms  109.928 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.769 ms  141.743 ms  141.368 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  134.981 ms  134.943 ms  134.842 ms
13  * * *
14  . (76.73.0.4)  134.575 ms  134.522 ms  134.483 ms

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  0.489 ms * *
 2  rbx-1-6k.routers.chtix.eu (188.165.9.129)  44.072 ms * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  5.715 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  11.749 ms  11.775 ms  11.770 ms
 5  if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.206 ms if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  5.939 ms if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.189 ms
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.972 ms  96.055 ms  95.979 ms
 7  63.243.186.66 (63.243.186.66)  101.114 ms  101.077 ms  101.075 ms
 8  Vlan551.icore1.NTO-NewYork.as6453.net (209.58.26.82)  96.503 ms Vlan546.icore1.NTO-NewYork.as6453.net (209.58.26.58)  96.641 ms Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.647 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  82.149 ms  82.117 ms  82.126 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  109.794 ms  109.879 ms  109.872 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.251 ms  141.245 ms  140.979 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  134.760 ms  134.754 ms  134.472 ms
13  . (76.73.0.4)  134.426 ms * *

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  3.167 ms * *
 2  rbx-1-6k.routers.chtix.eu (188.165.9.129)  2.452 ms * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  207.677 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  10.736 ms  10.730 ms  10.856 ms
 5  if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  6.001 ms  5.995 ms if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.020 ms
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.844 ms  95.686 ms  95.968 ms
 7  * * *
 8  Vlan550.icore1.NTO-NewYork.as6453.net (209.58.26.78)  96.633 ms Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.419 ms Vlan546.icore1.NTO-NewYork.as6453.net (209.58.26.58)  96.553 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  81.813 ms  81.810 ms  81.788 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  109.891 ms  109.849 ms  109.857 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.520 ms  141.526 ms  141.502 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  135.049 ms  135.171 ms  135.142 ms
13  . (76.73.0.4)  134.535 ms  134.863 ms  134.833 ms

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  43.956 ms * *
 2  rbx-1-6k.routers.chtix.eu (188.165.9.129)  183.015 ms * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  68.489 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  10.562 ms  10.565 ms  10.559 ms
 5  if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.255 ms if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  5.841 ms if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.237 ms
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.836 ms  95.956 ms  95.870 ms
 7  63.243.186.66 (63.243.186.66)  108.190 ms  104.026 ms  103.984 ms
 8  Vlan551.icore1.NTO-NewYork.as6453.net (209.58.26.82)  96.473 ms  96.534 ms Vlan550.icore1.NTO-NewYork.as6453.net (209.58.26.78)  96.718 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  82.592 ms  82.308 ms  82.581 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  110.029 ms  109.999 ms  110.035 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.492 ms  141.463 ms  141.467 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  134.594 ms  134.681 ms  134.706 ms
13  . (76.73.0.4)  134.591 ms  134.620 ms  134.789 ms

Der zweite Hop antwortet wieder nicht beim ersten Mal. Und dann das gleiche Spiel: Die ersten Hops antworten mal schnell, mal langsam. Allerdings immer nur die ersten Antwort. Keine Ahnung ob der Router so konfiguriert ist, vom 91er gab es immer eine Antwort.

Könnten andere, die dies lesen auch mal traceroutes zu diesen beiden Servern hier posten: 85.31.185.122 und 76.73.0.4 ? Damit es eine gewisse Vergleichbarkeit ergibt.
Selbst wenn das alles nicht so aussagekräftig ist, wie auch schon geschrieben wurde, im Vergleich zu dem bisherigen EG, ist die schlechtere Netzwerkqualität eindeutig bemerkbar. Was gibt es außer Ping und traceroute noch, um die Ursache einzugrenzen?

Neuer Server, neue Probleme. Bin ich froh, dass man hier monatliche Laufzeiten haben kann. Wenn das so weitergeht, bin ich bald wieder weg von OVH.

[Sascha]

hab nurn isgenug i7

naja da ich gameserver drauf laufen habe ist mir das bis dato nicht aufgefallen und somit nicht also wichtig für mich.

solange meine leute nicht wegen packetlost oder zu hohe pings auf die füße treten bin ich soweit zufrieden mit dem was ich hab.

desweiteren könnt ihr auch nix drann ändern wenn der engpass auf den weg zu ovh auftritt. oder werdet ihr auf grund dessen das routing ändern?

[strex]

Alle Server mit IP 188.165.* sollten im RBX3 stehen. Dort habe ich auch nen paar, laufen aber bis dato sauber =) Aber nicht vergleichbar mit den HG, die haben immer noch den besten Speed =)

[mathias]

Hallo,

je mehr Tickets von verschiedenen Personen zum gleichen Sachverhalt offen sind, umso schneller kann ein ggf. zentrales Problem lokalisiert und angegangen werden.

Mathias

[fastforward]

@Matthias,
Ticket eröffnen - das ist ja Spassig, seit über 5 Monate ist ein Ticket offen, was ist passiert bist jetzt seitens OVH nichts!

[mathias]

Hallo,

ruhig mal ein Störungsticket öffnen mit Traceroutes, Downloadlinks und den bisherigen Beobachtungen (Problem nur von bestimmten Netzbereichen o.ä.).

Mathias

[Sascha]

ich schaffe da gerade mal 40-60kb mit der iprange 188.165.*.* von zu hause voll speed.

aber ich denke das es nicht unbedingt an ovh liegen muss das kann auch schon eine begrenzung aufn weg zum ovh netzwerk sein.

[fuxifux]

Tja, so tappt man sehenden auges in fettnäpfchen... da hab ich glatt ein 'm' übersehn nur weil mir auf den ersten Blick 3 '0' gefehlt haben...

Was solls... live goes on...

[schwarzlicht]

schwarzlich: der 91er hat aber die gleiche Route bis dahin.

...

Schon klar, jedoch beweisen die hier geposteten Routen gar nichts. Da müssten schon andere Dinge her...

[pendulum]

fuxifux: 300.000 km/s sind 300 km/ms...

gerry: hah stimmt, hab ich nich beachtet, danke

[fuxifux]

Wenn wir schon bei Klugschei... sind:
Die Lichtgeschwindigkeit beträgt 300.000km/s, nicht 300km/s

Das Hauptproblem ist sicher, dass es noch keine Quantenprozessoren gibt, die in den Routern und Switches mit Lichtgeschwindigkeit 'rechnen'....

Edit: mit 2/3c hast du natürlich Recht....

[gerry]

Und 90-100ms is für ne Transatlantische Verbindung leider oft normal. Das sind vielleicht 6000km. Lichtgeschwindigkeit beträgt rund 300km pro ms. Das heisst 20ms allein schon für das Licht in den Glasfasern selber

Die Lichtgeschwindigkeit in Glasfaser beträgt 2/3 der Lichtgeschwindigkeit im Vakuum. In diesem Fall also 30ms nur damit das Licht den Altantik überquert.

Sorry für die Klugscheißerei, aber bei so ner Strecke macht das halt einen Unterschied...

[Kampfkatze]

Hier ein traceroute zum Testserver von euserv:

Vom 188er

1  188.165.212.254 (188.165.212.254)  9.178 ms * *
 2  * * *
 3  decix1.jena1.as35366.net (80.81.192.188)  34.414 ms  34.299 ms  34.489 ms
 4  hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1)  28.276 ms  28.058 ms  27.741 ms
 5  skynet3.web.kundencontroller.de (85.31.185.122)  26.893 ms  27.060 ms  26.846 ms

und vom 91er

traceroute to 85.31.185.122 (85.31.185.122), 30 hops max, 40 byte packets
 1  rbx-31-m2.routers.ovh.net (91.121.102.252)  0.778 ms  0.858 ms  0.995 ms
 2  * * *
 3  10g.fra-5-6k.routers.chtix.eu (91.121.131.81)  8.424 ms * *
 4  decix1.jena1.as35366.net (80.81.192.188)  34.820 ms  34.548 ms  34.621 ms
 5  hawk2-vl1610-10GE.jena1a.routers.as35366.net (81.7.0.1)  27.522 ms  27.172 ms  27.505 ms
 6  skynet3.web.kundencontroller.de (85.31.185.122)  27.127 ms  27.170 ms  26.884 ms

Das sieht man doch, dass der erste Hop beim einen mit 9ms und beim anderen 0.8ms reagiert.

Und dann pinge ich den Router direkt an

PING 188.165.212.254 (188.165.212.254) 56(84) bytes of data.
64 bytes from 188.165.212.254: icmp_seq=1 ttl=255 time=22.2 ms
64 bytes from 188.165.212.254: icmp_seq=2 ttl=255 time=0.364 ms
64 bytes from 188.165.212.254: icmp_seq=3 ttl=255 time=0.409 ms
64 bytes from 188.165.212.254: icmp_seq=4 ttl=255 time=30.6 ms
64 bytes from 188.165.212.254: icmp_seq=5 ttl=255 time=0.711 ms
64 bytes from 188.165.212.254: icmp_seq=6 ttl=255 time=3.41 ms
64 bytes from 188.165.212.254: icmp_seq=7 ttl=255 time=18.9 ms
64 bytes from 188.165.212.254: icmp_seq=8 ttl=255 time=0.580 ms
64 bytes from 188.165.212.254: icmp_seq=9 ttl=255 time=6.26 ms
64 bytes from 188.165.212.254: icmp_seq=10 ttl=255 time=0.942 ms
64 bytes from 188.165.212.254: icmp_seq=11 ttl=255 time=0.319 ms
64 bytes from 188.165.212.254: icmp_seq=12 ttl=255 time=27.3 ms
64 bytes from 188.165.212.254: icmp_seq=13 ttl=255 time=0.781 ms

64 bytes from 188.165.212.254: icmp_seq=14 ttl=255 time=120 ms

64 bytes from 188.165.212.254: icmp_seq=15 ttl=255 time=3.80 ms
64 bytes from 188.165.212.254: icmp_seq=16 ttl=255 time=0.343 ms
64 bytes from 188.165.212.254: icmp_seq=17 ttl=255 time=4.01 ms
64 bytes from 188.165.212.254: icmp_seq=18 ttl=255 time=0.367 ms

Und dann pinge ich den erste Router des 91ers:

PING 91.121.102.252 (91.121.102.252) 56(84) bytes of data.
64 bytes from 91.121.102.252: icmp_seq=1 ttl=255 time=4.71 ms
64 bytes from 91.121.102.252: icmp_seq=2 ttl=255 time=0.551 ms
64 bytes from 91.121.102.252: icmp_seq=3 ttl=255 time=0.546 ms
64 bytes from 91.121.102.252: icmp_seq=4 ttl=255 time=0.546 ms
64 bytes from 91.121.102.252: icmp_seq=5 ttl=255 time=0.546 ms
64 bytes from 91.121.102.252: icmp_seq=6 ttl=255 time=0.560 ms
64 bytes from 91.121.102.252: icmp_seq=7 ttl=255 time=0.540 ms
64 bytes from 91.121.102.252: icmp_seq=8 ttl=255 time=0.525 ms
64 bytes from 91.121.102.252: icmp_seq=9 ttl=255 time=0.731 ms
64 bytes from 91.121.102.252: icmp_seq=10 ttl=255 time=0.545 ms
64 bytes from 91.121.102.252: icmp_seq=11 ttl=255 time=0.601 ms
64 bytes from 91.121.102.252: icmp_seq=12 ttl=255 time=0.553 ms
64 bytes from 91.121.102.252: icmp_seq=13 ttl=255 time=0.587 ms
64 bytes from 91.121.102.252: icmp_seq=14 ttl=255 time=0.566 ms
64 bytes from 91.121.102.252: icmp_seq=15 ttl=255 time=0.534 ms
64 bytes from 91.121.102.252: icmp_seq=16 ttl=255 time=0.596 ms
64 bytes from 91.121.102.252: icmp_seq=17 ttl=255 time=0.655 ms
64 bytes from 91.121.102.252: icmp_seq=18 ttl=255 time=0.544 ms
64 bytes from 91.121.102.252: icmp_seq=19 ttl=255 time=0.674 ms

Durchgehend unter 1ms. Das Problem beginnt definitiv bei OVH.

[pendulum]

schwarzlich: der 91er hat aber die gleiche Route bis dahin.

Und 90-100ms is für ne Transatlantische Verbindung leider oft normal. Das sind vielleicht 6000km. Lichtgeschwindigkeit beträgt rund 300km pro ms. Das heisst 20ms allein schon für das Licht in den Glasfasern selber

Interessant wären jetz Traceroutes zu deutschen Servern. Wenn da keine Unterschiede sind dann liegts (und das vermute ich zZ) an OVH denn wie schon erwähnt ist es nicht nur ein User der über Bandbreitenprobleme in dem Netzsegment klagt.

[schwarzlicht]

 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  127.105 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  8.266 ms  8.305 ms *
 5  * * if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  5.963 ms

Wenn Hope 3 tatsächlich mit 127ms reagieren würde, wäre es im weiterem Verlauf nicht möglich wieder unter diesen Wert zu kommen, Hope 4 hat aber 8ms!!??

Dein Problem beginnt hier:

 5  * * if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  5.963 ms
 6  * if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.984 ms *

, ausserhalb von OVH.

[Kampfkatze]

So hier noch folgende logs:

Vom Server mit der 188:

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  * * *
 2  * * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  127.105 ms * *
 4  20g.teleglobe-2.ams.routers.ovh.net (94.23.122.130)  8.266 ms  8.305 ms *
 5  * * if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  5.963 ms
 6  * if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.984 ms *
 7  63.243.186.66 (63.243.186.66)  105.876 ms  102.123 ms  107.923 ms
 8  Vlan551.icore1.NTO-NewYork.as6453.net (209.58.26.82)  96.649 ms * Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.342 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  89.327 ms  88.763 ms  89.221 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  110.102 ms  109.605 ms  109.860 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.271 ms  141.153 ms  141.154 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  139.786 ms  134.684 ms  135.571 ms
13  * * *
14  . (76.73.0.4)  134.447 ms  134.559 ms  134.496 ms

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  188.165.212.254 (188.165.212.254)  14.794 ms * *
 2  rbx-1-6k.routers.chtix.eu (188.165.9.129)  1.847 ms * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  5.643 ms * *
 4  * * *
 5  if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  6.039 ms * if-1-0-0-82.core2.AD1-Amsterdam.as6453.net (80.231.81.25)  6.024 ms
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  95.756 ms *  95.538 ms
 7  63.243.186.66 (63.243.186.66)  108.047 ms  108.021 ms  100.040 ms
 8  Vlan550.icore1.NTO-NewYork.as6453.net (209.58.26.78)  97.009 ms Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.955 ms Vlan546.icore1.NTO-NewYork.as6453.net (209.58.26.58)  96.439 ms
 9  pos-1-10-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.73)  89.082 ms  89.085 ms  89.061 ms
10  pos-2-6-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.98)  109.837 ms  109.830 ms  109.796 ms
11  pos-1-12-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.250)  141.370 ms  141.368 ms  141.159 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  247.630 ms  247.517 ms  247.513 ms
13  . (76.73.0.4)  134.670 ms  134.463 ms  134.496 ms

Da sind ja bei den ersten beiden Hops schon Auffälligkeiten zu sehen. Selbst wenn man jetzt davon ausgeht, dass die Pakete nicht Priorität geroutet werden, wenn sie mal geroutet werden und mal nicht, bzw nur mit starker Verzögerung, dann ist der Router wohl busy oder falsch konfiguriert.

Im Vergleich vom 91......

traceroute to 76.73.0.4 (76.73.0.4), 30 hops max, 40 byte packets
 1  rbx-31-m2.routers.ovh.net (91.121.102.252)  0.730 ms  0.877 ms  1.041 ms
 2  rbx-1-6k.routers.ovh.net (213.251.191.1)  4.108 ms * *
 3  40g.ams-1-6k.routers.chtix.eu (213.251.130.66)  5.877 ms * *
 4  * * *
 5  if-5-0-0-1135.core2.AD1-Amsterdam.as6453.net (80.231.81.17)  6.547 ms * *
 6  if-15-0-0.core3.NTO-NewYork.as6453.net (80.231.81.46)  96.286 ms  95.773 ms  96.047 ms
 7  Vlan1297.icore1.NTO-NewYork.as6453.net (209.58.26.49)  96.228 ms  96.035 ms  95.871 ms
 8  * Vlan552.icore1.NTO-NewYork.as6453.net (209.58.26.86)  96.605 ms Vlan551.icore1.NTO-NewYork.as6453.net (209.58.26.82)  96.493 ms
 9  pos-1-8-0-0-cr01.newyork.ny.ibone.comcast.net (68.86.86.45)  90.140 ms  89.903 ms  89.762 ms
10  pos-2-9-0-0-cr01.chicago.il.ibone.comcast.net (68.86.86.110)  109.853 ms  109.989 ms  109.944 ms
11  pos-1-15-0-0-cr01.denver.co.ibone.comcast.net (68.86.85.114)  141.885 ms  141.814 ms  141.372 ms
12  comcast01.den.fdcservers.net (75.149.229.10)  135.174 ms  134.760 ms  134.562 ms
13  . (76.73.0.4)  134.748 ms  134.538 ms  134.442 ms

Man beachte mal den Unterschied beim ersten Hop.

Hier noch Pings vom 188er

PING 188.165.212.254 (188.165.212.254) 56(84) bytes of data.
64 bytes from 188.165.212.254: icmp_seq=1 ttl=255 time=116 ms
64 bytes from 188.165.212.254: icmp_seq=2 ttl=255 time=28.0 ms
64 bytes from 188.165.212.254: icmp_seq=3 ttl=255 time=25.3 ms
64 bytes from 188.165.212.254: icmp_seq=4 ttl=255 time=7.07 ms
64 bytes from 188.165.212.254: icmp_seq=5 ttl=255 time=5.62 ms
64 bytes from 188.165.212.254: icmp_seq=6 ttl=255 time=7.62 ms
64 bytes from 188.165.212.254: icmp_seq=7 ttl=255 time=4.17 ms
64 bytes from 188.165.212.254: icmp_seq=8 ttl=255 time=24.5 ms
64 bytes from 188.165.212.254: icmp_seq=9 ttl=255 time=0.795 ms
64 bytes from 188.165.212.254: icmp_seq=10 ttl=255 time=19.3 ms
64 bytes from 188.165.212.254: icmp_seq=11 ttl=255 time=0.450 ms
64 bytes from 188.165.212.254: icmp_seq=12 ttl=255 time=0.357 ms
64 bytes from 188.165.212.254: icmp_seq=13 ttl=255 time=8.28 ms
64 bytes from 188.165.212.254: icmp_seq=14 ttl=255 time=0.713 ms
64 bytes from 188.165.212.254: icmp_seq=15 ttl=255 time=0.471 ms
64 bytes from 188.165.212.254: icmp_seq=16 ttl=255 time=4.45 ms
64 bytes from 188.165.212.254: icmp_seq=17 ttl=255 time=5.41 ms
64 bytes from 188.165.212.254: icmp_seq=18 ttl=255 time=4.50 ms
64 bytes from 188.165.212.254: icmp_seq=19 ttl=255 time=2.65 ms
64 bytes from 188.165.212.254: icmp_seq=20 ttl=255 time=15.3 ms
64 bytes from 188.165.212.254: icmp_seq=21 ttl=255 time=1.21 ms
64 bytes from 188.165.212.254: icmp_seq=22 ttl=255 time=0.358 ms
64 bytes from 188.165.212.254: icmp_seq=23 ttl=255 time=0.455 ms
64 bytes from 188.165.212.254: icmp_seq=24 ttl=255 time=1.42 ms
64 bytes from 188.165.212.254: icmp_seq=25 ttl=255 time=2.48 ms
64 bytes from 188.165.212.254: icmp_seq=26 ttl=255 time=2.82 ms
64 bytes from 188.165.212.254: icmp_seq=27 ttl=255 time=3.89 ms
64 bytes from 188.165.212.254: icmp_seq=28 ttl=255 time=2.34 ms
64 bytes from 188.165.212.254: icmp_seq=29 ttl=255 time=0.360 ms
64 bytes from 188.165.212.254: icmp_seq=30 ttl=255 time=0.440 ms
64 bytes from 188.165.212.254: icmp_seq=31 ttl=255 time=0.439 ms
64 bytes from 188.165.212.254: icmp_seq=32 ttl=255 time=28.2 ms
64 bytes from 188.165.212.254: icmp_seq=33 ttl=255 time=19.1 ms
64 bytes from 188.165.212.254: icmp_seq=34 ttl=255 time=5.77 ms
64 bytes from 188.165.212.254: icmp_seq=35 ttl=255 time=0.527 ms
64 bytes from 188.165.212.254: icmp_seq=36 ttl=255 time=4.39 ms

[SenfDressing]

es scheint als wären viele server mit der ip 188....davon betroffen klagen ja genug...
von servern mit 91 er oder 94 er gehts ab

[Kampfkatze]

wget http://lg.denver.fdcservers.net/100MBtest.zip auf 91.121:
100%[================================================== ================================================== ===============>] 104.857.600 4,83M/s in 25s

2010-05-10 23:51:21 (3,96 MB/s) - »100MBtest.zip« gespeichert [104857600/104857600]

wget http://lg.denver.fdcservers.net/100MBtest.zip auf 188.165:
100%[================================================== ================================================== ===============>] 104.857.600 244K/s in 3m 45s

2010-05-10 23:55:14 (454 KB/s) - »100MBtest.zip.1« gespeichert [104857600/104857600]

Das ist ja wohl ein Witz oder? Der 91... ist ein EG, der 188 ein MG.

Bei Speedtests zu Anbietern in DE, liefern beide Server fast identische Ergebnisse, daher kann ein Fehler in der Netzwerkkonfiguration ausgeschlossen werden. Die Diskrepanz ist extrem.