Routing nach Österreich (UPC und Telekom Austria)
Bin erst jetzt dazu gekommen mir das weiter anzuschauen. Nachdem ich alle logfiles durchsucht hatte, die Configs gecheckt habe etc. und nichts auffälliges entdeckt habe, hab ich mich dazu entschlossen meinen FTP-Client neu zu installieren. Siehe da, jetzt klappts wieder. Lag also scheinbar doch nicht am Server und auch nicht am Routing, sondern wie immer am DAU vorm Rechner
Naja, danke trotzdem für deine Hilfe. Komm mir jetz mal wieder extra dumm vor.
Da bei mir auch andere Testfiles schlechte Speedwerte aufzeigen ist heute bei UPC wohl gerade happy Dienstag...
vielleicht verstopft jetzt Netflix auch in der EU peerings
Aus deiner Sicht würde ich mal die Serverconfig checken...
Was macht dein Server sonst noch?
Okok.
Gegengetestet mit folgenden Downloads:
1)
http://mirror.nl.leaseweb.net/speedtest/1000mb.bin
http://i.imgur.com/J9Lyd9l.jpg
2)
http://mirror.de.leaseweb.net/speedtest/1000mb.bin
http://i.imgur.com/XMLD1hZ.jpg
3) und hier wird's interessant weil ebenfalls bei OVH:
http://rbx.proof.ovh.net/files/1Gio.dat
http://i.imgur.com/t6cH0UC.jpg
Die letzten beiden sind für mich normal. Das OVH Testfile ist wohl besonders interessant. Aber was mach ich jetzt mit der Info? Worauf deutet das hin?
Thx übrigens für deine Hilfe.
Das sagt mir das wir zwar beide schwankende speeds haben, ich nicht so schlimm wie du - jedoch alle Datenpakete ankommen.
Ich lege das bei UPC in die Ablage "sucht euch mal gute Netzwerker"
hab das einfach zeitenweise...
Zieh du mal ein Testfile von einem anderen großen Hoster und prüfe mal gegen obs an der TA oder OVH liegt..
Ah ok.
Ping vom Server zu mir:
Code:
--- 178.191.169.xxx ping statistics ---
100 packets transmitted, 100 received, 0% packet loss, time 99122ms
rtt min/avg/max/mdev = 33.982/35.157/36.805/0.541 ms
und umgekehrt:
Code:
Ping-Statistik für 5.135.177.xxx:
Pakete: Gesendet = 287, Empfangen = 287, Verloren = 0
(0% Verlust),
Ca. Zeitangaben in Millisek.:
Minimum = 38ms, Maximum = 53ms, Mittelwert = 39ms
Dann sieht da ja eigentlich gut aus. Hmm. Also liegts am FTP?
nein, ich meinte tatsächlich einen ping...
ping 1.2.3.4 -n 60
>Schaut nicht gerade toll aus.
10 178-191-169-xx.adsl.highway.telekom.at (178.191.169.xx) 34.511 ms 34.929 ms 35.717 ms
35ms sind für adsl ja normal...
Hey tester,
hatte bisher wirklich nie Probleme seit ich vor einigen Jahren zu A1 wechselte, erst neuerdings.
Ich nehm an du meintest einen Traceroute und keinen Ping, oder?
Traceroute von mir zu OVH:
Code:
Routenverfolgung zu 5.135.177.xxx
über maximal 30 Hops:
1 1 ms 1 ms 1 ms A1MODEM [10.0.0.138]
2 21 ms 17 ms 15 ms 178-191-175-254.adsl.highway.telekom.at [178.191.175.254]
3 * 16 ms 15 ms 195.3.68.114
4 15 ms 15 ms 16 ms 195.3.68.113
5 15 ms 17 ms 18 ms 195.3.70.50
6 * 89 ms 201 ms vix.vie-1-6k.routers.ovh.net [193.203.0.151]
7 * 21 ms 21 ms pra-1-6k.cz.eu [213.251.128.97]
8 * * * Zeitüberschreitung der Anforderung.
9 37 ms 37 ms 37 ms rbx-g2-a9.fr.eu [94.23.122.117]
10 * 35 ms * vss-9b-6k.fr.eu [178.33.100.74]
11 36 ms 35 ms 36 ms 5.135.177.xxx
Ablaufverfolgung beendet.
Vom Server zu mir:
Code:
traceroute 178.191.169.xx
traceroute to 178.191.169.xx (178.191.169.xx), 30 hops max, 60 byte packets
1 vss-9a-6k.fr.eu (5.135.177.253) 0.322 ms * *
2 rbx-g2-a9.fr.eu (91.121.131.157) 1.027 ms 1.495 ms 1.488 ms
3 * fra-5-6k.fr.eu (91.121.131.133) 9.359 ms *
4 pra-1-6k.cz.eu (213.251.128.109) 15.808 ms * *
5 vie-1-6k.at.eu (213.251.128.98) 20.322 ms * *
6 vix2.highway.telekom.at (193.203.0.11) 26.549 ms 25.668 ms 25.539 ms
7 AUX10-IIX11.highway.telekom.at (195.3.70.217) 20.270 ms 195.3.118.29 (195.3.118.29) 20.210 ms 20.173 ms
8 195.3.68.114 (195.3.68.114) 4266.588 ms 2810.430 ms 2904.989 ms
9 178-191-175-254.adsl.highway.telekom.at (178.191.175.254) 30.138 ms 25.749 ms 24.989 ms
10 178-191-169-xx.adsl.highway.telekom.at (178.191.169.xx) 34.511 ms 34.929 ms 35.717 ms
@evolve
das beim Router anpingen(was dein mtr macht) packetloss auftritt ist normal!
Das wollte Marius damit uns/dir mitteilen.
Pinge doch mal direkt wie ich bereits vorgeschlagen habe und lass uns das ergebnis von 1 Minute oder länger zukommen...
Für längere Beobachtungen eignet sich smokeping recht gut
[Edit: nur damit hier keine Missverständnisse auftreten, diese Antwort ist an Marius gerichtet] Also ist da in deinen Augen alles normal? Für mich nämlich nicht. Erstens gibt's 100erte Beispiele im Internet von MRT Reports die ohne Packet Loss ablaufen und selbst wenn auf ICMP requests nicht immer geantwortet wird soll mir das zwar recht sein, aber das hier kein Problem vorliegt lass ich mir nicht einreden. Ich weiß nicht ob du die Grafik unten gesehen hast, aber normal ist das nicht.
Ich hab versucht möglichst viele Informationen bereitzustellen, und mich an das gehalten was die User weiter oben auch in etwa bereitgestellt haben. Ich kann nur von meinen derzeitigen und bisherigen Erfahrungen berichten. Ich bin seit 5 Jahren Kunde bei OVH, hatte ungefähr 1 Jahr lang grobe Probleme mit UPC (die hier auch im Thread nachvollziehbar sind), bin anschließend zu A1 gewechselt und hatte seither nie Probleme bis mir eben vor einigen Tagen zum ersten Mal aufgefallen ist das es jetzt offenbar welche gibt.
Falls du mir Tipps geben kannst wie ich deiner Meinung nach effektiver rausfinden kann wo das Problem liegt, bin ich gerne bereit dir zuzuhören, andernfalls wirkt dein Post einfach nur so als würdest du gerne deinen Postcount erhöhen.
MfG
ping mal direkt von deinem pc zuhause auf OVH und umgekehrt auf deinen Router zuhause....
deinen speedgraph via FTP kann ich vom UPC Netz aus bestätigen, der Durchsatz ist heute/jetzt gerade sehr schlecht...
Österreich braucht endlich mal einen guten Internetprovider!
http://weathermap.ovh.net/wien
Routenverfolgung zu *-ext [188.165.197.x]
über maximal 30 Hops:
1 <1 ms 1 ms <1 ms OpenWrt.lan [10.0.0.1]
2 2 ms 1 ms 2 ms FRITZ-NAS [192.168.178.1]
3 41 ms 36 ms 16 ms 84.116.231.161
4 13 ms 14 ms 16 ms 84.116.229.209
5 15 ms 14 ms 13 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]
6 33 ms 32 ms 32 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]
7 36 ms 38 ms 35 ms us-was02a-rd1-pos-1-0.aorta.net [213.46.160.106]
8 32 ms 34 ms 31 ms 84.116.132.170
9 40 ms 44 ms * fra-5-6k.de.eu [91.121.131.77]
10 45 ms 45 ms 43 ms rbx-g2-a9.fr.eu [91.121.131.134]
11 * 40 ms 40 ms vss-3-6k.fr.eu [213.251.130.77]
12 41 ms 41 ms 41 ms *-ext [188.165.197.x]
Ablaufverfolgung beendet.
Routenverfolgung zu 85-127-74-x.dynamic.xdsl-line.inode.at [85.127.74.x]
über maximal 30 Hops:
1 35 ms 1 ms * vss-3b-6k.fr.eu [188.165.197.252]
2 1 ms 1 ms 1 ms rbx-g1-a9.fr.eu [213.186.32.253]
3 * * * Zeitüberschreitung der Anforderung.
4 * 8 ms * fra-5-6k.fr.eu [94.23.122.222]
5 59 ms 203 ms 120 ms pra-1-6k.cz.eu [213.251.128.109]
6 201 ms 207 ms 198 ms vie-1-6k.at.eu [213.251.128.98]
7 * * * Zeitüberschreitung der Anforderung. [Dieser Router antwortet nie, laut Weathermap müssten da ja noch welche kommen ]
8 27 ms 27 ms 30 ms 213.46.173.126
9 27 ms 27 ms 27 ms at-grz-lazg-pe02-vl-2032.upc.at [84.116.228.86]
10 24 ms 23 ms 23 ms at-grz-mk43-pe01-vl-2084.upc.at [84.116.229.74]
11 27 ms 27 ms 27 ms 84.116.229.122
12 38 ms 40 ms 38 ms 85-127-74-x.dynamic.xdsl-line.inode.at [85.127.74.x]
Ablaufverfolgung beendet.
us-was02a-rd1-pos-1-0.aorta.net [213.46.160.106]
ist wohl aufgrund des niedrigen Pings falsch...
Zitat von
eVolvE
Was ist da los? Der PacketLoss scheint ja schon ganz früh und noch im OVH-Netz zu passieren. Könnt ihr das mal prüfen und hoffentlich beheben. Bin ich der einzige dem das hier auffällt?
Da tritt kein Packet Loss auf.
Die Router antworten nur nicht immer auf ICMP requests, was völlig normal ist.
Tut mir leid das ich den Thread mal wieder hervorholen muss, aber ich kann momentan nichts gutes über die Verbindung zwischen A1 und OVH berichten, oder generell irgendwohin.
Hier mal 3 MTR Reports vom Server zu einigen Zielen:
1. Ziel mein Rechner zu Hause, Provider A1
Code:
mtr --report 178.191.169.77
HOST: ks3285350.kimsufi.com Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-9a-6k.fr.eu 50.0% 10 0.5 2.8 0.4 12.1 5.2
2.|-- rbx-g2-a9.fr.eu 0.0% 10 1.0 1.1 0.8 2.2 0.4
3.|-- fra-5-6k.fr.eu 70.0% 10 8.4 36.6 8.4 52.9 24.5
| `|-- 94.23.122.118
4.|-- pra-1-6k.cz.eu 10.0% 10 182.0 97.1 15.9 182.0 72.4
5.|-- vie-1-6k.at.eu 10.0% 10 109.3 33.8 19.9 109.3 30.4
6.|-- vix2.highway.telekom.at 0.0% 10 23.8 27.4 22.5 30.1 2.7
7.|-- 195.3.70.53 0.0% 10 20.3 21.0 20.3 23.3 1.0
8.|-- 195.3.68.114 0.0% 10 21.2 26.3 21.2 38.0 5.6
9.|-- 178-191-175-254.adsl.high 0.0% 10 22.6 23.1 21.4 28.4 1.9
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
2. Ziel vom Server zu Google.com
Code:
mtr --report google.com
HOST: ks3285350.kimsufi.com Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-9b-6k.fr.eu 10.0% 10 1.0 7.1 0.7 54.8 17.9
2.|-- rbx-s2-6k.fr.eu 0.0% 10 0.7 8.2 0.7 44.9 13.7
3.|-- rbx-g2-a9.fr.eu 30.0% 10 0.9 1.2 0.9 2.0 0.4
4.|-- gsw-g1-a9.fr.eu 0.0% 10 4.7 4.8 4.6 4.9 0.1
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- google.as15169.fr.eu 0.0% 10 5.9 5.8 4.7 6.5 0.6
7.|-- 2001:4860::1:0:4a3a 0.0% 10 20.2 8.5 5.1 22.2 6.7
8.|-- 2001:4860::8:0:5e18 0.0% 10 5.4 5.3 5.2 5.5 0.1
9.|-- 2001:4860::8:0:507c 0.0% 10 9.5 9.7 9.5 9.8 0.1
10.|-- 2001:4860::8:0:6401 0.0% 10 28.1 28.0 27.8 28.1 0.1
11.|-- 2001:4860::8:0:4fc9 0.0% 10 40.7 40.8 40.6 41.1 0.2
12.|-- 2001:4860::8:0:59da 0.0% 10 49.3 54.3 49.1 59.6 3.8
13.|-- 2001:4860::2:0:6ad4 0.0% 10 49.8 50.4 49.6 56.3 2.1
14.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
15.|-- 2a00:1450:4010:c05::65 0.0% 10 49.8 49.7 49.6 49.9 0.1
3. Ziel vom Server zu einem Rechner im UPC Netzwerk:
Code:
mtr --report
HOST: ks3285350.kimsufi.com Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-9a-6k.fr.eu 10.0% 10 1.0 2.2 0.5 7.7 2.3
2.|-- rbx-g2-a9.fr.eu 0.0% 10 0.8 0.9 0.7 1.2 0.2
3.|-- fra-5-6k.fr.eu 80.0% 10 28.9 47.3 28.9 65.6 26.0
| `|-- 91.121.131.202
4.|-- pra-1-6k.cz.eu 0.0% 10 15.8 15.9 15.7 16.3 0.2
5.|-- vie-1-6k.at.eu 20.0% 10 20.1 21.2 19.9 28.5 3.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- 213.46.173.126 0.0% 10 20.4 20.6 20.4 20.8 0.1
8.|-- at-vie-sk11-pe06-vl-2048. 0.0% 10 21.9 21.4 21.2 21.9 0.2
9.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- chello06217xxxx100.13.11. 0.0% 10 35.8 31.3 29.2 35.8 1.9
Was ist da los? Der PacketLoss scheint ja schon ganz früh und noch im OVH-Netz zu passieren. Könnt ihr das mal prüfen und hoffentlich beheben. Bin ich der einzige dem das hier auffällt?
Zuletzt kann ich noch einen Graphen von Windows 8 anbieten der die Auslastung am Netzwerkcontroller bei mir zuhause anzeigt. Download eines großen Files über FTP vom besagten Server. Ich kann nur sagen, dass dieser Graph nicht normal ist und zB bei diversen Speedtests und sonstigen Übertragungen viel, viel konstanter ist als das hier.
http://i.imgur.com/XZRVo2E.jpg
Gestern Abend hatten wir gewohnte OVH Qualität, der smokeping von Caddy bestätigt das ja....
Interessehalber: Wo wird der Traffic aktuell übergeben?
Hop 9 antwortet ja leider nicht...
Pakete: Gesendet = 16744, Empfangen = 16727, Verloren = 17
Abends werd ich mich wieder melden...
Zitat von
Felix
Und, wie war's? :-)
Felix
Nun, basierend auf unserem Smokeping von GRA aus - Ungefähr so:
http://i.imgur.com/O5V2lqu.png
Das Test-Zielobjekt liegt im 213.47.x.x Subnet von UPC, Mein Kollege in Wien hat mir ebenfalls bestätigt, dass es gestern keine Probleme gab.
Das gilt aber nur für UPC :-)
Gruß, Klaus
Zitat von
tester
Jetzt gerade[17:00 - 17:20] gibts 0% loss
mal schauen wies am Abend ist...
Und, wie war's? :-)
Felix
Routenverfolgung zu 85-127-59-*.dynamic.xdsl-line.inode.at [85.127.59.*]
über maximal 30 Hops:
1 <1 ms * <1 ms 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g2-6k.qc.ca [198.27.73.19]
3 9 ms * * 198.27.73.206
4 * * * Zeitüberschreitung der Anforderung.
5 84 ms 85 ms 84 ms rbx-g2-a9.fr.eu [91.121.131.243]
6 95 ms * 102 ms fra-5-6k.fr.eu [94.23.122.118]
7 * 95 ms 95 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 154 ms 103 ms vie-1-6k.at.eu [213.251.128.98]
9 * * * Zeitüberschreitung der Anforderung.
10 110 ms 110 ms 112 ms at-vie01a-ra3-ge-0-1-0.aorta.net [213.46.173.118
]
11 110 ms 113 ms 110 ms at-grz-lazg-pe01-vl-2031.upc.at [84.116.228.82]
12 144 ms 133 ms 129 ms at-grz-mk47-pe01-vl-2086.upc.at [84.116.229.82]
13 110 ms 110 ms 110 ms 84.116.229.210
14 141 ms 141 ms 130 ms 85-127-59-*.dynamic.xdsl-line.inode.at [85.127.
59.*]
Ablaufverfolgung beendet.
laut Weathermap gehts noch übers Wien PNI
http://weathermap.ovh.net/wien ?
Jetzt gerade[17:00 - 17:20] gibts 0% loss
mal schauen wies am Abend ist...
Im Moment (ist ja mitten am Tag) sieht's noch gut aus.
Route von meinem Wiener Kollegen zu uns:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.126.2 0.0% 13 0.1 0.3 0.1 1.4 0.3
2. 192.168.0.1 0.0% 12 1.4 1.1 0.8 1.6 0.0
3. ???
4. 84.116.4.161 0.0% 12 10.3 11.8 8.6 19.4 3.8
5. at-vie15a-rd1-vl-2043.aorta.net 0.0% 12 48.9 32.0 17.4 64.6 12.8
6. 84.116.136.118 0.0% 12 24.2 26.7 19.0 43.5 7.4
7. 84.116.133.113 0.0% 12 26.1 24.9 20.6 33.5 3.4
8. fra-5-6k.de.eu 16.7% 12 44.0 25.8 20.0 44.0 7.5
9. sbg-g2-a9.fr.eu 0.0% 12 25.4 28.6 23.9 46.6 6.4
10. gsw-g1-a9.fr.eu 0.0% 12 30.5 33.7 29.5 43.1 4.8
11. gra-g1-a9.fr.eu 0.0% 12 35.6 36.5 33.9 42.7 2.4
gra-g1-a9.fr.eu
12. gra-3a-6k.fr.eu 63.6% 12 41.4 35.6 32.5 41.4 3.9
13. xxxxxxx.tv 0.0% 12 42.6 37.0 32.0 44.4 3.5
Vom Server nach Wien:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. gra-g2-a9.fr.eu 0.0% 18 1.1 0.9 0.8 1.2 0.1
3. th2-g1-a9.fr.eu 0.0% 18 5.0 5.0 4.9 5.2 0.1
4. sbg-g1-a9.fr.eu 0.0% 17 11.7 11.4 11.2 11.7 0.1
sbg-g2-a9.fr.eu
5. fra-1-6k.fr.eu 70.6% 17 13.3 14.8 13.3 19.1 2.5
6. fra-5-6k.fr.eu 37.5% 17 28.5 15.1 13.3 28.5 4.8
7. pra-1-6k.cz.eu 0.0% 17 46.2 22.5 20.7 46.2 6.2
8. vie-1-6k.at.eu 5.9% 17 25.0 25.0 24.9 25.4 0.1
9. ???
10. 213.46.173.126 0.0% 17 25.9 30.9 25.7 74.9 12.6
11. at-vie-sk11-pe02-vl-2043.upc.at 0.0% 17 26.9 27.0 26.9 27.1 0.0
12. ???
13. ???
14. chello213047xxxxxx.11.vie.surfer.at 0.0% 17 34.8 38.2 31.9 44.7 4.5
Vermutlich wird aber der Auslöser die Route von OVH nach UPC AT beim Ausstieg in Wien sein. Die Frage wäre, da UPC ja auch in Frankfurt mit OVH ein Peering betreibt, ob man zumindest UPC AT nicht direkt in Frankfurt übergeben kann, und den Transport einfach UPC selbst überlässt.
Aus meiner persönlichen langen Erfahrung (ich selbst habe Unitymedia (Auch UPC) und ich habe (das ist durchaus als Lob zu verstehen) seit dem UPC Peering in Frankfurt grundsätzlich immer Fullspeed und keinerlei Latenzprobleme und erst recht keinen Loss :-)
Gruß, Klaus
Hallo,
wir haben das Peering in Wien testweise deaktiviert - könnt ihr testen ob sich die Situation für euch dadurch verbessert hat?
MfG,
Felix
01.04.2014
00:22
vie-3-f10 -> UPC #1 und #2 bei 25%, 26%
pro Verbindung ~20kb/s
22% loss
für eine openvpn Verbindung, alsauch HTTP Dienstleistungen ist das der tot!
sollte ich hier nichts mehr hören werd ich ein Ticket eröffnen müssen...
*Dies ist kein Aprilscherz!
selbiges bei
OVH -> AS8445 83.215.0.0/16
1 21 ms 4 ms * 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g1-6k.qc.ca [198.27.73.17]
3 2 ms * * mtl-1-6k.qc.ca [198.27.73.0]
4 * * * Zeitüberschreitung der Anforderung.
5 * * * Zeitüberschreitung der Anforderung.
6 * * * Zeitüberschreitung der Anforderung.
7 130 ms 129 ms 130 ms rbx-g1-a9.fr.eu [91.121.215.141]
8 * * 171 ms fra-1-6k.de.eu [91.121.131.206]
9 139 ms 137 ms 139 ms fra-5-6k.fr.eu [94.23.122.218]
10 * 147 ms * pra-1-6k.cz.eu [213.251.128.109]
11 332 ms * 149 ms vie-1-6k.at.eu [213.251.128.98]
12 156 ms * 158 ms vix.sol.at [193.203.0.29]
.
.
.
HOP 4-6 antworten auch nach dem 4. trace nicht...
Ich sehe da eine Gemeinsamkeit, die ist euer Router in Wien...
(ich nehme mal an das bis dorthin alles funktioniert, sonst hätten auch noch andere diese Probleme)
Ist da der Link #2 down?
Ist zwar die andere Richtung, drüber geht trotzdem wenig...
meine Openvpn Verbindungen reißen auch gerne ab,...
Ich bin ja nicht so für's Pushen, aber:
http://s14.directupload.net/images/140323/saee72t5.png
und
http://s7.directupload.net/images/140323/uyvg7tts.png
sieht für mich so aus, als wenn die temporären Probleme über den vie-1-6k auf Kapazitätsprobleme hindeuten, oder?
Vielleicht müssen da noch ein paar "Strippen" mehr dran :-)
Gruß, Klaus
Ich nehme an, Du fragst deswegen:
http://s14.directupload.net/images/140320/syammc39.png
OVH Smokeping:
http://s1.directupload.net/images/140320/tqdahdqq.png
Eigener Smokeping (GRA):
http://s7.directupload.net/images/140320/dr85wpy6.png
Der Bekannte, der mich eben informiert hat, hat ausschliesslich Probleme nach OVH, zu allen anderen Anbietern nicht.
Leider ist es gerade heute wieder besonders schlimm...
Felix? (trommel)
Gruß, Klaus
Hallo zusammen,
Ich habe mal zum Vergleich ein paar Speedtests von meinem Bekannten aus Wien machen lassen, jetzt gerade eben, mitten in der Nacht bei freiem Netz:
OVH:
http://www.speedtest.net/my-result/3375606492
Frankfurt (LeaseWeb):
http://www.speedtest.net/my-result/3375608900
Luxemburg (P&T):
http://www.speedtest.net/my-result/3375612161
Utrecht (NL):
http://www.speedtest.net/my-result/3375614334
Limoges (wo immer das auch ist):
http://www.speedtest.net/my-result/3375615875
Die Aussage, dass höchstens 20 Mbit über das Vienna Peering gehen, ist ja damit schon fast bestätigt.
Egal, an wem das nun genau liegt (vorher hatte Felix ja schon einmal irgendwo geschrieben, dass seitens OVH dort nichts eingeschränkt wird), halte ich es wirklich für sinnvoll, dass sich da vielleicht beide Beteiligten (OVH und UPC) doch noch einmal in Verbindung setzen :-)
Die Speedtests wurden aus dem UPC Subnetz 213.47.x.x getätigt.
Gruß, Klaus
Ja
7 222 ms 143 ms 96 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 101 ms 104 ms vie-1-6k.at.eu [213.251.128.98]
prag und wien,
peering laut weathermap zu 30% ausgelastet...
Zitat von
iSO
vielleicht muss ich halt den nächsten server dort mieten.
Mach das.
Aber les vorher den Thread "Packetloss / Verbindungsabbrüche" in deren Forum.
Unitymedia (gehört auch zu LGI) <-> H. ist sehr schlimm in letzter Zeit, ständig packet loss und Latenzen über 100ms.
(routing über Level3, da H. immer noch kein direktes Perring mit LGI hat)
Meine 100mbits erreiche ich da zudem nie, bei ovh schon.
zu UPC in der Schweiz wirds wohl auch nie besser, obwohl auch hier das peering gemäss weathermap eigentlich nicht soooo stark ausgelastet sein sollte:
ovh-->upc
Code:
HOST: mein-server Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-5a-6k.fr.eu 0.0% 10 85.5 13.7 0.0 85.5 28.9
2.|-- rbx-g1-a9.fr.eu 0.0% 10 1.2 3.7 0.0 14.1 5.4
3.|-- fra-1-6k.de.eu 70.0% 10 7.0 8.2 7.0 10.6 2.1
| `|-- 94.23.122.209
4.|-- fra-5-6k.fr.eu 60.0% 10 243.9 67.4 8.1 243.9 117.7
5.|-- zur-1-6k.ch.eu 0.0% 10 19.6 25.3 14.4 99.6 26.2
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- 84.116.134.141 0.0% 10 16.9 17.0 14.6 19.2 1.3
8.|-- 84.116.200.242 0.0% 10 20.3 17.6 15.1 20.3 2.0
9.|-- 217-168-63-90.static.cablecom.ch 0.0% 10 18.3 18.1 15.5 20.2 1.5
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- mein-anschluss-bei-upc 0.0% 10 26.1 28.0 22.6 34.7 3.6
upc-->ovh
Code:
Start: Sat Mar 15 17:14:28 2014
HOST: iso-i7 Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.12.254 0.0% 10 0.2 0.3 0.2 0.5 0.0
2.|-- 84-74-16-1.dclient.hispeed.ch 0.0% 10 8.1 11.1 7.2 16.6 2.8
3.|-- 217-168-63-89.static.cablecom.ch 0.0% 10 18.9 16.9 8.5 31.2 6.7
4.|-- 84.116.200.241 60.0% 10 16.9 11.8 8.8 16.9 3.5
5.|-- ch-zrh01b-ra1-ae-1.aorta.net 0.0% 10 7.4 10.2 7.4 15.3 2.5
6.|-- zur-1-6k.ch.eu 0.0% 10 8.5 22.3 8.5 47.0 13.4
7.|-- fra-5-6k.fr.eu 20.0% 10 23.2 22.6 15.8 37.1 7.5
8.|-- rbx-g2-a9.fr.eu 0.0% 10 25.6 29.9 24.7 52.9 8.4
9.|-- vss-5a-6k.fr.eu 40.0% 10 28.5 29.4 25.2 39.5 5.2
10.|-- meinserver 0.0% 10 29.1 28.9 24.4 36.3 3.4
mein server steht in rbx, von proof.ovh.net krieg ich auch nicht mehr als die 5-20mbit (von der tageszeit abhängig). bei speedtest.net und auch aus steam etc. krieg ich eigentlich immer die 150mbit/s...
bei hetzner gibts auch einiges mehr....
Code:
Resolving www.hetzner.de (www.hetzner.de)... 213.133.107.227, 2a01:4f8:d0a:2001::2
...
2014-03-15 17:25:06 (3.90 MB/s) - ‘/dev/null’ saved [104840234/104840234]
vielleicht muss ich halt den nächsten server dort mieten. den vorteil, den ihr bisher hattet (das ich meine failover-ip weiternutzen kann) scheint ihr ja jetzt auch nicht mehr zu bieten (oder kann man jetzt failover-ips von ovh zu soy umziehen?)
Sind in Deiner Route von OVH zu UPC AT zufällig auch diese Punkte vorhanden:
Code:
6 pra-1-6k.cz.eu (213.251.128.109) 20.781 ms * *
7 vie-1-6k.at.eu (213.251.128.98) 24.969 ms * *
Irgendwie hat nämlich genau dieser Weg in den letzten Wochen ziemlich oft ziemliche Probleme wie Packet Loss, langsame Übertragung und / oder auch beides zusammen.
Das Peering am vie-1-6k ist dabei aber nicht ausgelastet, zumindest nicht laut weathermap.
Ich selbst bin ja auch schon länger UPC (Unitymedia, die wurden ja von LGI gekauft), ich bin aber in DE und hier klappt das Peering, was in Frankfurt seinerzeit eingerichtet wurde, hervorragend.
Für meine Bekannten in Österreich (und einem guten Freund in Wien) wäre das natürlich ein Traum, wenn das dort genau so zuverlässig funktionieren könnte :-)
Gruß, Klaus
Hetzner -> UPC gut
Leaseweb -> UPC gut
OVH -> UPC schlecht
OVH -> Telekom Austria gut
ovh -> hetzner/ leaseweb kann ich derzeit nicht testen...
sorry, das ich nochmal nachhake... meinst du OVH => (Hetzner|Leaseweb) oder (Hetzner|Leaseweb) => UPC ?
Kannst du eventuell beides mal testen?
Ich bin bei A1, bei mir passt eigentlich alles. (Rz GRA)
Hallo Felix!
von hetzner und leaseweb ja...
Um sicher zu gehen und andere Einflüsse auszuschliessen - von nicht-UPC Gegenstellen können höhere Durchsätze erreicht werden?
Felix
Hallo Felix!
Consumer aus dem Bereich
Announced as 85.127.0.0/16 (UPC Austria GmbH)
Announced as 85.126.0.0/15 (UPC Austria GmbH)
Announced as 85.124.0.0/14 (UPC Austria GmbH)
bekommen 24/7 ca. 1-2 mbit, auch von proof.ovh.net
Seit ihr mit UPC in Kontakt?
Grüße
Traceroute to AS6830
C:\Users\admin>tracert 85.127.36.xxx
Routenverfolgung zu 85-127-36-xxx.dynamic.xdsl-line.inode.at [85.127.36.xxx]
über maximal 30 Hops:
1 26 ms <1 ms * 142.4.211.252
2 1 ms 1 ms 1 ms bhs-g2-6k.qc.ca [198.27.73.19]
3 * 9 ms * 198.27.73.206
4 78 ms * * ldn-5-6k.qc.ca [198.27.73.10]
5 91 ms 85 ms 86 ms rbx-g2-a9.fr.eu [178.33.100.79]
6 * * 101 ms fra-5-6k.fr.eu [178.33.100.245]
7 222 ms 143 ms 96 ms pra-1-6k.cz.eu [213.251.128.109]
8 102 ms 101 ms 104 ms vie-1-6k.at.eu [213.251.128.98]
9 * * * Zeitüberschreitung der Anforderung. (Timeout)
10 108 ms 107 ms 107 ms 213.46.173.126
11 107 ms 108 ms 108 ms at-grz-lazg-pe02-vl-2032.upc.at [84.116.228.86]
12 109 ms 108 ms 108 ms at-grz-mk43-pe01-vl-2084.upc.at [84.116.229.74]
13 108 ms 108 ms 107 ms 84.116.229.218
14 121 ms 119 ms 122 ms 85-127-36-xxx.dynamic.xdsl-line.inode.at [85.127.36.xxx]
Ablaufverfolgung beendet.
Traceroute to OVH
C:\Users\H>tracert [bhs1 (T01B29)]
Routenverfolgung zu
über maximal 30 Hops:
1 2 ms 1 ms 1 ms fritz.box [192.168.178.1]
2 14 ms 20 ms 12 ms 84.116.231.162
3 19 ms 19 ms 22 ms 84.116.229.213
4 19 ms 19 ms 20 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]
5 23 ms 24 ms 23 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]
6 24 ms 24 ms 26 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117]
7 27 ms * 23 ms vie-1-6k.at.eu [91.121.131.65]
8 * * 23 ms pra-1-6k.cz.eu [213.251.128.97]
9 31 ms 32 ms * fra-5-6k.fr.eu [213.251.128.110]
10 40 ms 42 ms 43 ms rbx-g2-a9.fr.eu [94.23.122.117]
11 * * 61 ms ldn-5-6k.uk.eu [91.121.131.240]
12 * * * Zeitüberschreitung der Anforderung.
13 159 ms 138 ms 126 ms bhs-g2-6k.qc.ca [198.27.73.207]
14 155 ms * 122 ms bhs-3a-6k.qc.ca [198.27.73.14]
15 123 ms 124 ms 121 ms xxx [142.4.211.xxx]
Ablaufverfolgung beendet.
Zitat von
Felix
davon ausgehend das es sich um eine IP im Netz 213.47.x.x handelt, sollte es nun besser sein - über eine Rückmeldung würden wir uns freuen!
Felix
Jetzt passt es. Und ja, es war eine IP aus diesem Netz, ich hatte sporadisch vorher schonmal durchgesehen, es wäre egal gewesen, welche IP ihr zum testen genommen hättet, denn das ganze Netz ging diesen merkwürdigen Weg.
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. ???
2. gra-g1-a9.fr.eu 0.0% 6 0.8 0.9 0.8 1.1 0.1
3. gsw-g1-a9.fr.eu 60.0% 6 4.7 5.1 4.7 5.5 0.5
4. gsw-2-6k.fr.eu 83.3% 6 9.9 9.9 9.9 9.9 0.0
5. th2-g1-a9.fr.eu 16.7% 6 5.0 4.9 4.8 5.0 0.1
th2-g1-a9.fr.eu
6. sbg-g2-a9.fr.eu 0.0% 6 11.3 11.5 11.3 11.6 0.1
7. fra-5-6k.fr.eu 33.3% 6 13.5 13.4 13.4 13.5 0.1
8. pra-1-6k.cz.eu 0.0% 6 20.9 52.2 20.8 189.8 67.8
9. vie-1-6k.at.eu 33.3% 6 25.0 25.1 25.0 25.1 0.1
10. ???
11. 213.46.173.126 0.0% 6 25.6 25.5 25.5 25.6 0.1
12. at-vie-sk11-pe02-vl-2043.upc.at 0.0% 5 48.6 30.3 25.7 48.6 10.2
13. ???
14. ???
15. chello2130470xx0xx.11.vie.surfer.at 0.0% 5 44.1 38.8 33.1 44.2 5.0
Getestet habe ich das mit derselben IP wie eingangs auch.
Vielen Dank, das ging wirklich fix
Gruß, Klaus
davon ausgehend das es sich um eine IP im Netz 213.47.x.x handelt, sollte es nun besser sein - über eine Rückmeldung würden wir uns freuen!
Felix
$ host chello2130470xx0xx.11.vie.surfer.at
Host chello2130470xx0xx.11.vie.surfer.at not found: 3(NXDOMAIN)
Um das problem nachzuvollziehen bräuchten wir die IP mit welcher das Problem bei dir aufgetreten ist - wenn du sie nicht im forum haben willst sonst auch per mail.
Gruß,
Felix
Hallo,
Danke für die Rückmeldung. UPC scheint uns das Netzwerk nicht komplett zu announcen, wir werden daher mit UPC in Kontakt treten und um ein korrektes Announce bitten.
Felix
Vielleicht könntet ihr noch diese kleine "Weltreise" etwas verkürzen:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. rbx-6-m1.fr.eu 0.0% 35 0.5 0.5 0.4 0.8 0.1
2. rbx-1-6k.fr.eu 0.0% 35 1.6 4.0 0.3 65.9 12.3
3. rbx-g1-a9.fr.eu 0.0% 35 0.9 1.9 0.6 16.4 3.0
4. fra-1-6k.de.eu 76.5% 35 14.0 12.9 7.9 24.9 7.6
fra-1-6k.de.eu
fra-1-6k.de.eu
fra-1-6k.de.eu
5. fra-5-6k.fr.eu 76.5% 35 7.9 52.9 7.9 312.7 106.6
6. ???
7. if-4-1108.tcore1.FNM-Frankfurt.as6453.net 0.0% 35 8.2 8.6 8.2 9.8 0.4
8. if-7-2.tcore1.FR0-Frankfurt.as6453.net 0.0% 35 12.2 11.6 11.2 12.6 0.4
9. if-4-2.tcore1.PVU-Paris.as6453.net 0.0% 34 21.9 12.1 11.0 21.9 2.4
10. 80.231.153.98 0.0% 34 33.6 33.7 33.5 34.6 0.2
11. nl-ams04a-ri2-xe-9-2-1-2345.aorta.net 0.0% 34 34.4 36.7 33.8 44.8 3.3
12. 84.116.134.30 0.0% 34 34.9 36.7 34.0 51.5 5.3
13. at-vie-sk11-pe01-vl-2042.upc.at 0.0% 34 34.4 36.3 33.8 83.9 8.9
14. at-vie-sk11-pe02-vl-2044.upc.at 0.0% 34 33.8 36.4 33.7 82.9 9.7
15. ???
16. ???
17. chello2130470xx0xx.11.vie.surfer.at 0.0% 34 43.1 44.9 36.7 58.4 4.1
Code:
inetnum: 213.47.18.0 - 213.47.39.255
netname: CHELLO
descr: UPC Austria GmbH
descr: DHCP Range
country: AT
Das geht wohl noch über TATA - Die Hin-Route aus Wien passt bereits.
Gruß, Klaus
EDIT: ne, doch nicht besser. scheint eher zufall gewesen zu sein
Ja es hat sich scheinbar gebessert, die Form der Speedverteilung ist aber noch die selbe (zuerst ca. 3 sek Top-Speed, danach recht konstant 20mbit) - aber eben, viel besser als auch schon:
Code:
2013-12-10 07:26:54 (7.10 MB/s) - ‘/dev/null’ saved [262144000]
2013-12-10 07:28:28 (4.97 MB/s) - ‘/dev/null’ saved [262144000]
2013-12-10 07:30:16 (3.02 MB/s) - ‘/dev/null’ saved [262144000]
proof ist lustigerweise derzeit langsamer für mich als mein eigener server ziemlich genau 20mbit/s
Hallo,
hab einen 150mbit Anschluss bei UPC Wien und zumindest was den proof.ovh.net speedtest angeht ist die performance eigentlich perfekt. Ich lade fast mit fullspeed 130-150mbit das file herunter - also anscheinend passt nun wieder alles (den link hab ich verwendet: ttp://proof.ovh.net/files/10Gb.dat)
dafür habe ich nun probleme mit hosteurope - hab dort noch restbestände an server aber nun lade ich von dort mit 300kb runter -. also irgenwie hakts doch wohl imme wie es scheint daher suche ich alternativen, da der speed einfach nicht tragbar ist .... aber das ist eine andere geschichte
hier noch das traceroute zu ovh von upc wien aus:
Code:
tracert proof.ovh.net
Routenverfolgung zu proof.ovh.net [188.165.12.106]
über maximal 30 Hops:
1 <1 ms <1 ms <1 ms toxi-router [192.168.1.1]
2 * * * Zeitüberschreitung der Anforderung.
3 51 ms 8 ms 9 ms 84.116.25.113
4 20 ms 9 ms 19 ms at-vie-xion-pe01-vl-2098.upc.at [84.116.229.129]
5 * 7 ms 8 ms 213.46.173.125
6 36 ms * 51 ms vie-1-6k.at.eu [91.121.131.65]
7 * 38 ms * pra-1-6k.cz.eu [213.251.128.97]
8 * 31 ms * fra-5-6k.fr.eu [213.251.128.110]
9 41 ms 40 ms 40 ms rbx-g2-a9.fr.eu [178.33.100.244]
10 39 ms 40 ms * rbx-s3-6k.fr.eu [213.186.32.166]
11 31 ms 46 ms 33 ms proof.ovh.net [188.165.12.106]
iSO wrote:
> also... müsste man versuchen bei upc ein ticket zu eröffnen?
ja.
also... müsste man versuchen bei upc ein ticket zu eröffnen? oder wie könnten wir der lösung näher kommen?
ich nehme an das peering mit upc wurde wegen dem bandbreitenproblem gemacht - wie kann es denn sein dass nicht dabei direkt festgestellt wurde, dass das bandbreitenproblem quasi identisch besteht?
OK, das Routing ist symmetrisch...
Das NOC hat im Laufe dieser Woche nochmal sämtliche Router, ports und -konfigurationen überprüft, von unserer Seite gibt es keinen Grund das deine Bandbreite recht niedrig ist, es muss sich dabei also um ein bug oder "feature" seitens UPC handeln.
ja, hier:
Code:
1: 192.168.12.250 0.142ms pmtu 1500
1: 192.168.12.254 2.580ms
1: 192.168.12.254 2.520ms
2: no reply
3: 217-168-63-89.static.cablecom.ch 11.306ms
4: 84.116.211.25 12.674ms asymm 8
5: 84.116.202.241 11.784ms
6: ch-zrh01b-ra1-ae-9-0.aorta.net 17.208ms asymm 5
7: zur-1-6k.ch.eu 11.839ms asymm 6
8: fra-5-6k.fr.eu 17.605ms asymm 7
9: rbx-g2-a9.fr.eu 26.530ms asymm 8
10: vss-5a-6k.fr.eu 29.681ms
11: 87-98-xxx-xx.ovh.net 68.850ms reached
Resume: pmtu 1500 hops 11 back 54
ping ist aber besser als hier gezeigt:
Code:
150 packets transmitted, 150 received, 0% packet loss, time 149224ms
rtt min/avg/max/mdev = 24.490/27.082/37.511/3.058 ms
Zitat von
iSO
sieht bei mir jetzt so aus (ovh -> cablecom ch)
Hast du noch einen traceroute in die andere Richtung? (cablecom => OVH)
Danke,
Felix
sieht bei mir jetzt so aus (ovh -> cablecom ch) ... ist doch identisch wie vorher?:
Code:
HOST: mein-server Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-5a-6k.fr.eu 0.0% 10 36.7 47.8 0.6 193.0 69.3
2.|-- rbx-g1-a9.fr.eu 0.0% 10 1.0 1.0 0.8 1.4 0.1
3.|-- fra-1-6k.de.eu 60.0% 10 8.3 18.3 8.3 47.0 19.1
| `|-- 94.23.122.209
4.|-- fra-5-6k.fr.eu 30.0% 10 51.6 19.1 8.1 51.6 17.5
5.|-- zur-1-6k.ch.eu 10.0% 10 15.2 75.2 15.2 195.6 84.4
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- 84.116.134.141 0.0% 10 15.5 15.7 15.5 16.5 0.3
8.|-- 84.116.200.242 0.0% 10 16.3 17.1 16.3 18.5 0.8
9.|-- 217-168-63-90.static.cabl 0.0% 10 17.7 17.5 16.7 19.4 0.8
10.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
11.|-- 84-74-xx-xx.dclient.hispe 0.0% 10 24.1 24.3 23.1 25.6 0.7
speed auch praktisch identisch:
Code:
2013-10-31 14:40:38 (1.29 MB/s) - `/dev/null' saved [262144000]
Die traceroutes sehen doch schonmal viel besser aus. Werde noch weiteres feedback abwarten bevor wir das intern validieren...
Geht jetzt in beide Richtungen direkt, soweit die Hops zu sehen sind. Danke.
Cablecom CH => OVH
Code:
1 7 ms 3 ms 7 ms fritz.box [192.168.178.1]
2 17 ms 27 ms 14 ms 84-72-48-1.dclient.hispeed.ch [84.72.48.1]
3 15 ms 24 ms 24 ms 217-168-57-25.static.cablecom.ch [217.168.57.25]
4 27 ms 34 ms 27 ms 84.116.211.25
5 25 ms 24 ms 23 ms 84.116.202.241
6 27 ms 26 ms 25 ms de-fra03a-rd1-xe-3-2-0.aorta.net [213.46.160.53]
7 22 ms 22 ms 24 ms 84.116.132.162
8 34 ms * 24 ms fra-5-6k.de.eu [91.121.131.77]
9 32 ms 33 ms 31 ms rbx-g2-a9.fr.eu [91.121.131.134]
10 * 33 ms * vss-7a-6k.fr.eu [91.121.128.119]
11 63 ms 31 ms 30 ms meinovhserver [x.x.x.x]
Ablaufverfolgung beendet.
OVH => Cablecom CH
Code:
1 vss-7a-6k.fr.eu (176.31.126.253) 0.351 ms * *
2 rbx-g1-a9.fr.eu (91.121.128.114) 0.735 ms 1.232 ms 1.536 ms
3 * * *
4 fra-5-6k.fr.eu (94.23.122.222) 8.169 ms * *
5 zur-1-6k.ch.eu (94.23.122.146) 15.282 ms * *
6 * * *
7 84.116.134.141 (84.116.134.141) 14.828 ms 14.832 ms 15.798 ms
8 84.116.200.242 (84.116.200.242) 15.453 ms 15.569 ms 15.847 ms
9 XXX.dclient.hispeed.ch (x.x.x.x) 27.596 ms !X 27.658 ms !X 25.870 ms !X
Die maximale Downloadgeschwindigkeit gemäss proof.ovh.net ist jedoch scheinbar ggü. anderen speedtest.net Ergebnissen auf ca. 25 Mbps begrenzt(können andere mit schnellerer Anbindung bestimmt genauer sagen, für mich ist das nicht so wichtig).
Hallo,
Es wurden einige Änderungen am Routing mit UPC vorgenommen, die insbesondere für unsere Kunden in der Schweiz positive Auswirkungen haben sollten.
Könnt ihr sagen ob es nun besser ist? Idealerweise mit einem traceroute in beide Richtungen (also UPC => OVH und OVH => UPC) um zu prüfen ob alles so geklappt hat wie geplant
Felix
Yahoodi ich kauf dir deinen Server ab...
christiandyndns gmail.com
bei Interesse
hat sich OVH bzgl. dieser Thematik seit der Einführung des Peerings eigentlich wieder einmal geäussert?
Würde ich wohl auch tun, aber in der Schweiz ist die Alternative nicht so gross. Es gibt eigentlich gegen UPC nur noch die Swisscom, aber die liefert an meinem Wohnort "nur" 30 Mbit allerdings auch für mehr Geld :-)
UPC funktioniert hier schon ganz OK, selbst von Servern in Polen bekomme ich 140 Mbit. Das Peering zu OVH ist mit Abstand das schlechteste. Ich glaube selbst Neuseeland geht besser ;-)
Ja gut, wenn man nur einen vServer zum Spielen hat, kann man das machen.
Ich persönlich hab auch Konsequenzen gezogen, die besseren:
Ich habe meinen unitymedia Anschluss (ist ja auch UPC/LGI) zum Ende des Jahres gekündigt, und das schon vor Monaten, bevor es das PNI gab, und die Probleme anfingen.
Achja: und unsere Kunden die sich über Geschwindigkeitsprobleme beschweren, und bei einem ISP Kunde sind, der zu LGI gehört bekommen von uns auch immer diesen einzig richtigen Ratschlag: einfach den ISP wechseln.
Ich für meinen Teil werde die Konsequenzen wohl ziehen und meine OVH-Kiste kündigen. Bei einem Mitbewerber in DE (Köln) habe ich einen V-Server von dem ich zur schlechtesten Zeit 80 Mbit bekomme. Da ich viel mit Owncloud arbeite sind die 6 Mbit pro TCP Stream einfach nicht haltbar. Ob da jetzt UPC oder OVH der Buhmann ist, ist mir mitlerweile sch*** egal. Sie hatten ihre Chance und ich habe keine Zeit mehr für warten und basteln.
Ende der Durchsage :-)
bene wrote:
> Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus
Nein... Das PNI wurde ja, trotz erheblicher Kosten, geradeeben eingerichtet um
einen Flaschenhals zu verhindern, nicht um einen neuen zu haben.
dann is das routing zur und von deiner schule besser als von ovh zu dir
bzw. die uplinks ausreichend dimensioniert
Zitat von
bene
Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus Kostengründen, denn zu sehr ausgelastet ist das Interconnect nicht und selbst mitten in der Nacht sieht es nicht anders aus.
Und warum sollte OVH das tun, wenn es nicht stark ausgelastet ist?
Macht überhaupt keinen Sinn, OVH zahlt ja nicht nach Traffic.
Ich würde eher wetten, dass es an UPC/LGI liegt, an wem sonst.
Es geht über das PNI (bezahlter Interconnect) am CHTIX.
Aber bei mir genau das gleiche Problem, es ist wie "gedrosselt" auf 10MBit/s / Verbindung.
OVH und UPC schieben sich wie immer gegenseitig die Schuld dafür in die Schuhe und angeblich gemacht hat keiner was...
Ich würde fast vermuten, OVH drosselt dort den Speed künstlich aus Kostengründen, denn zu sehr ausgelastet ist das Interconnect nicht und selbst mitten in der Nacht sieht es nicht anders aus.
Greiffe ich über meinen IPv6 Tunnel von HE.net (getunnelt über meinen upc Anschluss) dagegen auf das OVH Netz zu erreiche ich auch jederzeit die maximale Leistung meines Anschlusses...
Zitat von
Yahoodi
aber wenn ich das 10 mal mache, hat trotzdem jeder Stream die gleiche Geschwindigkeit.
du meinst, dass du mit 5 parallelen verbindungen 5 mal so viel gesamtübertragungsrate hast wie mit nur einer verbindung?
das sehe ich auch, auch wenn sichs bei mir eher so um die 2.5 bewegt...
allerdings ist dies nicht für alle dienste ein gangbarer weg
stossend ist halt auch, dass ich bei mir zuhause eine um ein vielfaches schnellere übertragung erreiche, wenn ich mich via vpn ins netz der schule einwähle;
direkt:
Code:
2013-10-22 17:15:54 (1.19 MB/s) - `/dev/null' saved [262144000]
via schul-vpn:
Code:
2013-10-22 17:13:13 (7.86 MB/s) - ‘/dev/null’ saved [262144000]
route:
Code:
1.|-- vss-5a-6k.fr.eu 0.0% 15 0.5 15.8 0.5 158.4 41.3
2.|-- rbx-g1-a9.fr.eu 0.0% 15 1.0 1.0 0.9 1.1 0.1
3.|-- fra-1-6k.de.eu 66.7% 15 13.7 9.3 8.1 13.7 2.5
| `|-- 178.33.100.249
| |-- 91.121.131.194
4.|-- ??? 100.0 15 0.0 0.0 0.0 0.0 0.0
5.|-- zur-1-6k.ch.eu 0.0% 15 15.3 18.2 15.3 33.5 6.0
6.|-- ??? 100.0 15 0.0 0.0 0.0 0.0 0.0
7.|-- 84.116.134.141 0.0% 15 14.6 15.6 14.6 18.4 1.3
8.|-- 84.116.200.242 0.0% 15 18.3 18.5 18.3 19.4 0.3
9.|-- 217-168-63-90.static.cabl 6.7% 15 18.9 19.2 18.7 19.8 0.4
10.|-- ??? 100.0 15 0.0 0.0 0.0 0.0 0.0
11.|-- 84-74-xx-xx.dclient.hispe 0.0% 15 26.7 29.2 25.5 37.8 3.8
geht der traffic denn nun nicht über das peering (?) am chtix? sollte dadurch der speed nicht besser ausfallen?
wie ist bei euch der speed? für test:
Bei mir auch so 400-600 kB/Sek. - aber wenn ich das 10 mal mache, hat trotzdem jeder Stream die gleiche Geschwindigkeit. Von meinem eigenen Server hab ich das gleiche. Hab mich schon gewundert wieso Owncloud neuerdings so lange braucht.
das routing scheint sich ja geändert zu haben ... aber bzgl. geschwindigkeit scheint sich bei mir nicht viel getan zu haben
Code:
2013-09-29 18:47:00 (634 KB/s) - ‘/dev/null’ saved [262144000]
traceroute vom server zu mir:
Code:
1 vss-5a-6k.fr.eu (46.105.121.253) 27.262 ms * 0.653 ms
2 rbx-g2-a9.fr.eu (178.33.100.70) 0.872 ms 0.926 ms 0.920 ms
3 fra-5-6k.fr.eu (178.33.100.245) 10.353 ms fra-5-6k.fr.eu (94.23.122.118) 8.038 ms *
4 zur-1-6k.ch.eu (94.23.122.146) 15.416 ms * 15.476 ms
5 * * *
6 84.116.134.141 (84.116.134.141) 25.990 ms 15.456 ms 19.480 ms
7 84.116.200.242 (84.116.200.242) 18.488 ms 18.455 ms *
8 * (...ich)
wie ist bei euch der speed? für test:
Code:
wget -O /dev/null http://proof.ovh.net/files/100Mio.dat
Ich glaube das Netz 94.23.13.xxx scheint in mehrere Teile geteilt zu sein x.127 hat z.B. eine andere Route als x.128 und so weiter. Vielleicht hat jedes Rack seine eigene Route :-)
Hi,
vermute da ist wieder mal ein Reverse DNS Eintrag falsch, bie mir sieht es zu dem genannten Netz gut aus:
Code:
HOST: netstal.smooth-status.de Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 0.8 0.8 0.7 1.1 0.1
2.|-- 80-219-132-1.dclient.hispeed.ch 0.0% 10 33.7 15.5 8.5 33.7 8.9
3.|-- 217-168-55-173.static.cablecom.ch 0.0% 10 10.8 13.5 9.7 21.8 4.0
4.|-- 84.116.200.245 10.0% 10 24.4 26.2 21.5 34.5 3.9
5.|-- 84.116.136.174 0.0% 10 26.6 24.6 21.6 28.3 2.6
6.|-- 84.116.133.113 0.0% 10 35.7 30.7 21.5 53.6 10.4
7.|-- fra-5-6k.de.eu 30.0% 10 19.9 24.4 19.5 43.0 8.4
8.|-- rbx-g2-a9.fr.eu 0.0% 10 37.9 38.0 35.1 53.0 5.4
9.|-- vss-1b-6k.fr.eu 0.0% 10 33.4 53.1 33.4 87.7 19.6
| `|-- 91.121.131.29
10.|-- ks367714.kimsufi.com 0.0% 10 36.0 37.4 34.2 43.4 3.4
bei mir geht die Hin-Route zu OVH noch über Prag (allerdings wohl nur zum 94.23.13.0/24-Netz, alle anderen mir bekannten OVH-Netze gehen direkt über FRA):
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. 192.168.192.1 0.0% 67 4.4 0.9 0.4 12.1 1.8
2. 80-219-128-1.dclient.hispeed.ch 0.0% 67 13.1 14.7 11.7 26.7 2.9
3. 217-168-56-65.static.cablecom.ch 0.0% 67 13.7 14.2 12.2 21.4 1.6
4. 84.116.211.25 0.0% 67 20.4 21.0 18.5 34.1 2.2
5. 84.116.202.241 14.9% 67 20.0 28.1 19.7 60.5 9.3
6. cz-prg02a-ra2-xe-3-0-0.aorta.net 0.0% 67 26.7 20.9 18.0 29.4 2.4
7. 84.116.132.162 0.0% 67 22.8 23.7 21.0 72.9 6.5
8. fra-5-6k.de.eu 34.8% 66 20.1 26.4 18.6 84.2 16.7
9. rbx-g2-a9.fr.eu 0.0% 66 34.7 35.1 31.6 123.4 11.1
10. vss-1-6k.fr.eu 13.6% 66 32.3 51.5 31.3 235.0 45.8
vss-1b-6k.fr.eu
11. 94.23.13.xxx 0.0% 66 26.7 26.5 24.9 29.6 1.1
Zurück gehts korrekt FRA-ZRH.
Speed ist in beiden Richtungen aber trotzdem OK.
Vielleicht steht die Büchse gar nicht in Prag und nur der PTR-Record ist falsch ;-)
Zitat von
tester
"Die bekommen wir erst im Dezember mit dem Nikolaus wieder rein"
Aber mal Ernst beiseite - Meines Erachtens reicht das auch, wenn die Hin Route in Frankfurt übergeben wird, denn der UPC Backbone bis Frankfurt scheint dick genug zu sein, es würde meiner Meinung nach keinen Vorteil bringen, auch die Hin-Route über zur-1-6k.ch.eu zu führen, denn letztendlich landet die eh danach in Frankfurt :-)
Die Übergaben von OVH nach UPC (Wien) über TATA in Frankfurt anstatt über das PNI finde ich da schon unglücklicher.
Gruß, Klaus
Ich kenne die UPC Austria Hotline leider zu gut um die Antwort abzuschätzen können...
"Was ist eine Route?"
Von dir aus zu OVH ist aber UPC der Ansprechpartner. UPC entscheidet hier wo der Traffic übergeben wird. Da solltest du dich an UPC wenden, mit der Bitte.
Hi, habe grad gesehn zu mir geht es nun endlich von OVH zu upc über das PNI in Zürich:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. vss-9a-6k.fr.eu 11.3% 186 0.9 15.7 0.4 330.8 43.6
2. rbx-g2-a9.fr.eu 0.0% 186 0.9 3.2 0.7 47.7 8.4
3. fra-5-6k.fr.eu 45.9% 186 12.9 15.4 12.8 53.4 8.8
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
4. zur-1-6k.ch.eu 2.7% 186 19.9 32.4 19.8 267.3 41.5
5. ???
6. ch-zrh02a-ra1-xe-3-2-0.aorta.net 0.0% 186 20.0 22.7 19.6 64.5 4.6
7. 84.116.202.246 0.0% 186 24.6 23.7 23.6 25.3 0.2
8. 217-168-55-174.static.cablecom.c 0.5% 186 25.2 25.8 24.9 71.5 3.5
9. ???
10. 80-219-132-xxx.dclient.hispeed.c 0.0% 186 35.9 36.6 33.6 68.4 3.8
Aber von mir zu OVH wird der Traffic weiterhin in FFM übergeben, kann man das nicht auch in ZRH übergeben?
Code:
HOST: netstal.smooth-status.de Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.0.1 0.0% 10 0.8 0.8 0.7 0.9 0.1
2.|-- 80-219-132-1.dclient.hispeed.ch 0.0% 10 8.5 13.1 7.9 49.5 12.8
3.|-- 217-168-55-173.static.cablecom.ch 0.0% 10 9.8 11.0 9.4 18.2 2.6
4.|-- 84.116.200.245 20.0% 10 22.3 23.2 21.5 27.7 1.9
5.|-- 84.116.136.214 0.0% 10 21.2 22.9 21.2 28.9 2.3
6.|-- 84.116.132.194 0.0% 10 23.9 25.6 23.9 34.1 3.0
7.|-- fra-5-6k.de.eu 40.0% 10 23.3 29.4 22.3 45.4 8.8
8.|-- rbx-g2-a9.fr.eu 0.0% 10 36.0 38.4 36.0 43.3 3.0
9.|-- vss-9b-6k.fr.eu 0.0% 10 36.5 42.9 35.3 92.7 17.5
| `|-- 91.121.131.156
10.|-- 5.39.79.x 0.0% 10 44.1 39.0 36.5 44.1 2.8
Das UPC Routing nach Wien geht übrigens noch immer über TATA:
Code:
1 rbx-6-m1.fr.eu (87.98.216.253) 0.697 ms 0.853 ms 0.988 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 0.243 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 0.695 ms 0.927 ms 0.989 ms
4 * * *
5 * * *
6 if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133) 12.778 ms 12.685 ms 13.658 ms
7 if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1) 14.093 ms 14.094 ms 14.108 ms
8 213.46.179.137.aorta.net (213.46.179.137) 13.828 ms 13.827 ms 13.441 ms
9 84.116.132.185 (84.116.132.185) 25.939 ms 27.325 ms 27.024 ms
10 84.116.136.117 (84.116.136.117) 25.561 ms 25.431 ms 26.864 ms
11 at-vie-sk11-pe02-vl-2043.upc.at (84.116.228.130) 25.550 ms 25.451 ms 25.521 ms
12 chello213047115xxx.20.11.vie.surfer.at (213.47.115.xxx) 34.376 ms 40.660 ms 40.780 ms
Ich weiß, UPC müsste das entsprechend announcen aber irgendwie hält dieser Zustand schon recht lange an. Die Hin-Route geht ja schon über's PNI...
Gruß, Klaus
Oder eben über lambdanet, geht auch zügig:
Code:
traceroute to 84.116.229.81 (84.116.229.81), 30 hops max, 60 byte packets
1 gateway.ipv4.fra.filemedia.net (62.113.241.1) [AS47447] 0.258 ms 0.207 ms 0.179 ms
2 62.80.98.141 (62.80.98.141) [AS13237/AS8218] 0.573 ms 0.543 ms 0.557 ms
3 ae4.irt1.fra25.de.as13237.net (217.71.96.69) [AS13237] 0.872 ms 0.898 ms 0.916 ms
4 AMS-2-pos300.nl.lambdanet.net (82.197.128.18) [AS13237] 23.192 ms 23.295 ms 23.422 ms
5 nl-ams09b-ri1-ge-7-1-0.aorta.net (213.46.183.13) [AS6830] 23.083 ms 23.056 ms 23.028 ms
6 nl-ams05a-rd2-xe-4-2-2.aorta.net (84.116.130.21) [AS6830] 15.408 ms 84.116.136.82 (84.116.136.82) [AS6830] 15.502 ms nl-ams05a-rd2-xe-4-2-2.aorta.net (84.116.130.21) [AS6830] 15.341 ms
7 at-vie01a-rd1-xe-0-2-0.aorta.net (84.116.130.82) [AS6830] 48.384 ms 79.665 ms 79.612 ms
8 at-grz-lazg-pe01-vl-2031.upc.at (84.116.228.82) [AS6830] 90.256 ms 61.680 ms *
Ich glaube langsam nichtmehr an ein peering in FFM
Habe die frage auch mal oles auf twitter gestellt, leider keine antwort drauf erhallten, obwohl er dort wohl sehr redselig ist.
P.s. in den Niederlanden nutzen fast alle anbieter
Atrato IP um daten ins UPC netz zu schicken und das funktionert sehr gut, wäre ja evtl auch für OVH eine alternative zu TaTa.
1 tge1-1.fra02-1.de.as5580.net (78.152.61.241) [AS5580] 0.224 ms
2 upc-6830-ic.fra02-1.de.as5580.net (78.152.43.150) [AS5580] 0.230 ms
3 84.116.132.177 (84.116.132.177) [AS6830] 0.656 ms
4 84.116.133.113 (84.116.133.113) [AS6830] 0.598 ms
5 84-116-131-150.aorta.net (84.116.131.150) [AS6830] 0.605 ms
gibt es Neuigkeiten hierzu? der Durchsatz zu mir nach CH ist unverändert tief
Zitat von
iSO
Das verwundert mich eben auch, allerdings ist Hop 6 ja ein Router von aorta. Und Hop 5 trägt AS6830 im Namen...
ist der gleiche laden AS6830 ist Liberty Global die haben UPC ( Aorta ) aufgekauft.
Zitat von
Eddy
komisch ist das schon, da ja in der schweiz ein peering mit UPC besteht welches ja laut traceroute auch genutzt wird.
Das verwundert mich eben auch, allerdings ist Hop 6 ja ein Router von aorta. Und Hop 5 trägt AS6830 im Namen...
Zitat von
iSO
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich? am morgen erreiche ich etwa 1mbyte/s, gegen abend etc eher 300kbyte/s - von anderen anschlüssen (insbesondere an der uni) erreiche ich _immer_ volle 100mbit/s von diesem server
zu zeiten an denen ich von diesem server nur ca 300kbyte/s erreiche, erhalte ich von anderen servern sehr hohe bandbreiten (also eine auslastung des lokalen tv-kabelnetzes ist nicht vorhanden zu diesem zeitpunkt)
hier der pfad vom server zum user:
Code:
[iso@meinserver ~]$ mtr **** --report -c 50
HOST: meinserver Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-5b-6k.fr.eu 0.0% 50 1.4 10.1 0.6 119.7 23.9
2.|-- rbx-g2-a9.fr.eu 0.0% 50 1.3 2.4 0.9 29.4 5.0
3.|-- fra-5-6k.fr.eu 74.0% 50 42.9 11.1 8.3 42.9 9.5
| `|-- 178.33.100.255
| |-- 91.121.131.202
4.|-- zur-1-6k.ch.eu 0.0% 50 15.4 23.8 15.3 346.6 47.1
5.|-- upc.as6830.ch.eu 0.0% 50 14.6 15.4 14.6 42.3 3.9
6.|-- ch-zrh02a-ra1-xe-3-2-0.ao 0.0% 50 16.7 20.3 16.2 52.8 10.7
7.|-- 84.116.202.226 0.0% 50 16.9 16.8 16.5 17.2 0.1
8.|-- 84.116.211.22 0.0% 50 16.8 16.7 16.5 17.1 0.1
9.|-- 217-168-63-26.static.cabl 2.0% 50 17.9 21.0 17.6 61.3 9.6
10.|-- *************.dynamic.his 0.0% 50 25.0 27.8 23.8 39.7 3.6
komisch ist das schon, da ja in der schweiz ein peering mit UPC besteht welches ja laut traceroute auch genutzt wird.
UPC ist häufig nun mal langsam, gewöhnt euch dran
Zitat von
iSO
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich?
Ja, betrifft alle bei denen das Routing über Aorta (
AS6830) läuft.
Also auch UPC Schweiz Kunden.
ist diese thematik eigentlich auch für den schlechten durchsatz zu den UPC-Kunden in der schweiz verwantwortlich? am morgen erreiche ich etwa 1mbyte/s, gegen abend etc eher 300kbyte/s - von anderen anschlüssen (insbesondere an der uni) erreiche ich _immer_ volle 100mbit/s von diesem server
zu zeiten an denen ich von diesem server nur ca 300kbyte/s erreiche, erhalte ich von anderen servern sehr hohe bandbreiten (also eine auslastung des lokalen tv-kabelnetzes ist nicht vorhanden zu diesem zeitpunkt)
hier der pfad vom server zum user:
Code:
[iso@meinserver ~]$ mtr **** --report -c 50
HOST: meinserver Loss% Snt Last Avg Best Wrst StDev
1.|-- vss-5b-6k.fr.eu 0.0% 50 1.4 10.1 0.6 119.7 23.9
2.|-- rbx-g2-a9.fr.eu 0.0% 50 1.3 2.4 0.9 29.4 5.0
3.|-- fra-5-6k.fr.eu 74.0% 50 42.9 11.1 8.3 42.9 9.5
| `|-- 178.33.100.255
| |-- 91.121.131.202
4.|-- zur-1-6k.ch.eu 0.0% 50 15.4 23.8 15.3 346.6 47.1
5.|-- upc.as6830.ch.eu 0.0% 50 14.6 15.4 14.6 42.3 3.9
6.|-- ch-zrh02a-ra1-xe-3-2-0.ao 0.0% 50 16.7 20.3 16.2 52.8 10.7
7.|-- 84.116.202.226 0.0% 50 16.9 16.8 16.5 17.2 0.1
8.|-- 84.116.211.22 0.0% 50 16.8 16.7 16.5 17.1 0.1
9.|-- 217-168-63-26.static.cabl 2.0% 50 17.9 21.0 17.6 61.3 9.6
10.|-- *************.dynamic.his 0.0% 50 25.0 27.8 23.8 39.7 3.6
zakazak wrote:
> routing wieder im eimer.. grade zufällig aufgefallen.. 300kbit/s max.
Ich verweise auf folgenden Thread mit allen aktuellen Infos:
http://forum.ovh.de/showthread.php?t=11748
routing wieder im eimer.. grade zufällig aufgefallen.. 300kbit/s max.
lächerlich
Oder Strato.
http://s7.directupload.net/images/130114/jxefj8gu.png
Abwarten oder Provider wechseln. Wie schon geschrieben, habe ich mittlerweile das selbe Problem, seitdem Unitymedia erfolgreich in LGI reingefrickelt wurde.
Gruß, Klaus
Dann solltest du einmal in´s Heztner Forum reinschauen und die Threads zu LGI (United Media, KabelBw, UPC,..) anschauen. Das sieht´s nur bitter aus, aber wenn das so gut ist, warum bist du dann noch hier? Bitte sei aber danach nicht enttäuscht..
@ Strex
Wenn ich Speedtests auf Hetzner & Leaseweb durchführe erreiche ich meine 100 mbit, zwar nicht grade mit der besten Ping aber ich hab vollen Speed.
MFG
Leb damit oder Wechsel, pass aber auf, Heztner und co. haben dieselbe Problematik..Immer groß ankündigen und dann doch nicht machen, zeugt für mich von einfacher heißen Luft.
Mag sein, aber dann hätte man vorher nicht groß reden sollen ....
Nun gut Jänner ist noch nicht vorbei, aber so wies aussieht wird wieder nur vertröstet, dann heissts "Im Februar dann" und dann komt "Ist sich nicht ausgegangen März"....
Und so verliert man seine Kunden
Ich glaube UPC hat aktuell auch einfach keine Zeit und Lust dazu, gerade durch die Sache mit Unitymedia ...
Deren Netz ist überlastet genug, die haben aktuell wohl erst mal wichtigere Baustellen.
So jetzt hätten wir Jänner. Wie siehts denn jetzt mit der Lösung aus?
Bei der Geschwindigkeit hat sich nach wie vor nichts geändert...
MFG
Ist ja interessant, wieso schafft es in diesem fall TaTa direkt in FFM den traffic an Aorta zu übergeben.
Bei einer UM IP geht das erstmal über 2 andere Länder.
Code:
1 if-0-1-2-0.tcore1.FR0-Frankfurt.as6453.net (195.219.50.133) [MPLS: Label 564320 Exp 0] 60 msec 16 msec 16 msec
2 if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2) [MPLS: Label 319328 Exp 0] 12 msec
if-9-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.42) [MPLS: Label 319328 Exp 0] 16 msec
if-7-2.tcore1.FNM-Frankfurt.as6453.net (195.219.50.2) [MPLS: Label 319328 Exp 0] 16 msec
3 if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13) [MPLS: Label 304496 Exp 0] 16 msec
if-6-3.tcore1.AV2-Amsterdam.as6453.net (195.219.194.77) [MPLS: Label 304496 Exp 0] 16 msec
if-5-2.tcore1.AV2-Amsterdam.as6453.net (195.219.194.13) [MPLS: Label 304496 Exp 0] 12 msec
4 if-2-2.tcore2.AV2-Amsterdam.as6453.net (195.219.194.6) [MPLS: Label 304512 Exp 0] 16 msec 16 msec 16 msec
5 if-8-2.tcore2.L78-London.as6453.net (80.231.131.5) 16 msec
if-7-2.tcore2.L78-London.as6453.net (80.231.152.14) 16 msec 12 msec
6 Vlan757.icore2.LDN-London.as6453.net (80.231.20.21) 12 msec
Vlan756.icore2.LDN-London.as6453.net (80.231.131.26) 16 msec 12 msec
7 213.46.179.105.aorta.net (213.46.179.105) [AS 6830] 16 msec 16 msec 12 msec
8 uk-lon01b-rd1-xe-7-0-0.aorta.net (84.116.133.229) [AS 6830] 16 msec 16 msec 16 msec
9 1411g-mx960-02-ae3.neuss.unity-media.net (84.116.131.146) [AS 6830] 12 msec 12 msec 16 msec
10 13NOC-MX960-02-ae9.krp.unity-media.net (80.69.107.5) [AS 20825] [MPLS: Label 613279 Exp 0] 16 msec 12 msec 12 msec
11 13NOC-MX960-01-ae0.krp.unity-media.net (80.69.107.201) [AS 20825] [MPLS: Label 531148 Exp 0] 16 msec 20 msec 16 msec
12 7111A-MX960-01-ae8.fra.unity-media.net (80.69.107.25) [AS 20825] 16 msec 12 msec 20 msec
ich bin privat schon lange von upc geflüchtet....
Zitat von
strex
Beide Richtungen sind nicht die Besten, sind aber von UPC so gewünscht. Für deinen Fall den Zugangsanbieter wechseln, wenn dir das Routing nicht passt.
gerade gekündigt , nach 7jahren , das war halt meine lösung weg von inode der tochter von upc . wobei ich schon einmal von upc geflüchtet bin damals zu inode (leider vor paar jahren aufgekauft von upc um die geflüchteten kunden wieder zu bekommen)
naja schaun ma ab 1.2.2013 neuer isp und dann neuen ovh server
danke für die hilfe strex
Beide Richtungen sind nicht die Besten, sind aber von UPC so gewünscht. Für deinen Fall den Zugangsanbieter wechseln, wenn dir das Routing nicht passt.
heist das - wenn ich mich mit ftp zum ovh server binde - wählt der ftp die langsame komisch route und somit schickt ovh zu mir über die andere route udn nicht über tata
udn somit bricht die geschwindigkeit ein - weil ich schaff nur zw 70-300kb/s obwohl 2mbit mögich sind
oder versteh ich das jetzt falsch?
Kein Problem (Wie schon bekannt über TATA):
Code:
traceroute to 84.116.231.160 (84.116.231.160), 30 hops max, 60 byte packets
1 vss-7a-6k.fr.eu (176.31.119.253) 0.560 ms * *
2 rbx-g2-a9.fr.eu (91.121.128.118) 2.327 ms 2.337 ms 2.315 ms
3 fra-5-6k.fr.eu (178.33.100.251) 7.952 ms * *
4 tata.as6453.de.eu (213.251.130.106) 9.280 ms 9.186 ms 9.213 ms
5 if-4-1108.tcore1.FNM-Frankfurt.as6453.net (195.219.156.133) 8.491 ms 8.410 ms 8.376 ms
6 if-9-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.41) 8.824 ms 8.900 ms if-7-2.tcore1.FR0-Frankfurt.as6453.net (195.219.50.1) 8.620 ms
7 213.46.179.137.aorta.net (213.46.179.137) 8.610 ms 8.466 ms 8.545 ms
8 84.116.132.145 (84.116.132.145) 8.423 ms 84.116.132.173 (84.116.132.173) 8.687 ms 84.116.132.145 (84.116.132.145) 8.599 ms
9 fr-par02a-rd1-pos-2-0.aorta.net (213.46.160.105) 22.597 ms 84.116.136.117 (84.116.136.117) 22.066 ms 84.116.136.109 (84.116.136.109) 21.513 ms
10 at-vie-xion-pe01-vl-2050.upc.at (84.116.228.194) 23.392 ms 22.400 ms at-vie-xion-pe02-vl-2051.upc.at (84.116.229.2) 22.547 ms
11 at-vie-xion-pe04-vl-2056.upc.at (84.116.228.206) 46.798 ms at-vie-xion-pe04-vl-2055.upc.at (84.116.229.10) 47.297 ms at-vie-xion-pe04-vl-2056.upc.at (84.116.228.206) 46.536 ms
12 * * *
aber könntest du mal ein traceroute zu mir von deinem ovh server machen
wäre interesant wie ovh zu inode(upc) routet
Auch hier wird von UPC in´s AS3320 geroutet und dann zu OVH, ein Problem von OVH ist das nicht, da die Rückroute nicht von OVH sondern von UPC bestimmt wird.
so sieht ein tracert zu einem bekannten von mir aus der nen ovh server hat
also inode (upc) zu ovhserver
Routenverfolgung zu ns383xxx.ovh.net [46.105.xxx.xx] über maximal 30 Abschnitte:
1 <1 ms 1 ms 1 ms fritz.box
2 27 ms 26 ms 29 ms 84.116.231.160
3 59 ms 42 ms 41 ms 84.116.229.197
4 78 ms 41 ms 27 ms at-vie-xion-pe02-vl-2054.upc.at [84.116.228.201]
5 66 ms 43 ms 28 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 78 ms 32 ms 27 ms 213.46.173.125
7 29 ms 40 ms 39 ms 80.150.169.233
8 48 ms 54 ms 46 ms 217.239.40.230
9 * * * Zeitüberschreitung der Anforderung.
10 57 ms 57 ms 57 ms rbx-g1-a9.fr.eu [178.33.100.252]
11 48 ms * 68 ms vss-5b-6k.fr.eu [178.33.100.30]
12 53 ms 49 ms 55 ms ns383763.ovh.net [46.105.xxx.xx]
Ablaufverfolgung beendet.
und so zu einem anderen ovh server
Routenverfolgung zu ks220xxx.kimsufi.com [188.165.xxx.xxx] über maximal 30 Absch
nitte:
1 <1 ms <1 ms 1 ms fritz.box [192.168.178.1]
2 35 ms 27 ms 29 ms 84.116.231.160
3 35 ms 112 ms 39 ms 84.116.229.205
4 28 ms 27 ms 32 ms at-vie-xion-pe02-vl-2058.upc.at [84.116.228.209]
5 31 ms 28 ms 29 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 31 ms 39 ms 27 ms 213.46.173.125
7 30 ms 33 ms 28 ms 80.150.169.233
8 42 ms 50 ms 47 ms 217.239.39.26
9 41 ms * * fra-1-6k.de.eu [94.23.122.153]
10 50 ms 52 ms 61 ms rbx-g1-a9.fr.eu [178.33.100.242]
11 50 ms * 74 ms vss-4-6k.fr.eu [94.23.122.160]
12 49 ms 49 ms 50 ms ks220xxx.kimsufi.com [188.165.xxx.xxx]
Ablaufverfolgung beendet.
ich bin ein laie , aber für mich sieht das aus als hätte da die von ovh bzw franzosen ein problem (wie gesagt kenn mich da ned so aus viell kannst einer genauer interpredieren)
Spannende Route :-)
Das mit den mehreren Verbindungen ist übrigens anscheinend je nach Auslastung des UPC Netzes eine UPC Angelegenheit. Mein Kontakt in Wien hat das ab und zu auch zu / von anderen Servern. Wir haben das mal mit ihm und einem Strato-Server getestet, er bekam dort manchmal Fullspeed (100 Mbit/s), zu Hauptzeiten schonmal 50 MBit/s pro TCP Stream, oder auch 25 MBit/s pro Stream (man beachte diese haargenaue runde Teilung). Das Problem wird aber schon seit langer Zeit an diversen Stellen im Netz diskutiert.
LG, Klaus
Deine Verbindung läuft auch nicht über TATA oder UPC direkt sondern über das AS3320 (DTAG). Ziemlich komisch eigentlich, sollte nicht so sein. Bis jetzt gab es nie eine Route bei der die DTAG als Durchgangsnetz dient.
C:\Users\Admin>tracert host.org
Routenverfolgung zu host.org [***.***.***.***] über maximal 30 Abschnitte:
1 * * * Zeitüberschreitung der Anforderung.
2 29 ms 31 ms 39 ms 10.255.118.1
3 62 ms 64 ms 62 ms at-grz-lazg-pe01-vl-2086.upc.at [84.116.229.81]
4 55 ms 67 ms 63 ms at-vie01a-rd1-vl-2031.aorta.net [84.116.228.81]
5 51 ms 58 ms 45 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117
]
6 46 ms 58 ms 47 ms 80.150.169.233
7 41 ms 44 ms 43 ms 217.239.39.34
8 53 ms * * fra-1-6k.de.eu [94.23.122.153]
9 43 ms 49 ms 48 ms rbx-g1-a9.fr.eu [91.121.131.193]
10 83 ms 87 ms 79 ms vss-8b-6k.fr.eu [91.121.215.213]
11 98 ms 89 ms 58 ms host.org [***.***.***.***]
Ablaufverfolgung beendet.
ich bekomme immer Fullspeed (18mbit) symetrisch...
allerdings brauch ich dazu manchmal 2-3 Verbindungen, wobei die Leitung ja nicht nur mir gehört
Zitat von
nenad
Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
OVH besitzt mit UPC ein eigenes Peering. Siehe Weathermap..
Zitat von
nenad
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Gibt es doch schon lange, OVH besitzt mit allen eigene Peerings. Siehe Weathermap..
Zitat von
nenad
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an.... wobei dieser zu allen ISP top angebunden ist.... liegt daran das zahlreiche Video- und Filesharing Portale dort gehostet werden und da hat jeder ISP Freude daran
Das stimmt Leaseweb hat 3 Tbit/s, OVH hat nur 2 Tbit/s. Wobei nach neuerster Aussage von Oles (paar Tage) nur knapp 40% ausgelastet sind. Was Leaseweb aber fehlt ist ein weltweite Backbone, wie es eben OVH gerade aufbaut. Da gehen eben mal 200 Gbit/s über den Teich und in kleinerer Menge bis nach Tokio und HongKong. Somit ist man in der Lage den Traffic dort zu übergeben (Weltweit) wo es am Besten ist. Man darf eines nicht vergessen, es bringt unendlich viel Kapazität nichts, wenn man die Netze selbst nicht kontrolliert.
Was es in diesem Fall ist, ist reine Politik ähnlich wie mit der Telekom und hat keinerlei technische Grundlage..
Zitat von
Hook
Peerings mit z.B. UPC oder auch der Deutschen Telekom musst du i.d.R. einkaufen. Ich glaube das hatte er gemeint.
Das mag ja sein. Ich glaube aber, ein Geschäftsmodell, bei dem man durch zubuchbaren Premium Traffic zu bestimmten Providern / AS bessere Geschwindigkeiten bekommt, ist eher kontraproduktiv.
Es geht ja auch (hat er wohl auch überlesen) um den Upstream von OVH nach UPC über vie-3-f10. Auch, wenn direktes Peering zwischen UPC und OVH in keiner Peering DB steht (es findet wohl keins statt), oxydiert dieses Gerät da nun mal in Wien herum und tut nicht das, was es soll. Auf welcher Seite auch immer, das versuchten wir ja gerade rudimentär herauszubekommen :-)
Ich glaube kaum, dass OVH den Upstream nach UPC drosselt, also muss ja da etwas schief laufen.
Nebenbei:
( Thu, 6 Dec 2012 16:56:54 +0100 (CET) ) Ihre Email wurde an die zuständige Abteilung weitergeleitet und wird schnellstmöglich bearbeitet.
Gruß, Klaus
Zitat von
Caddy
IP Transit? Um aus einem Netz A (UPC) in ein Netz B (OVH) zu kommen, soll OVH IP Transit bei UPC kaufen? Möchtest Du das nicht nochmal überdenken? IP Transit kaufe ich, wenn ich durch ein Netz durch will, nicht, wenn ich direkt etwas "von" einem Netz will.
Peerings mit z.B. UPC oder auch der Deutschen Telekom musst du i.d.R. einkaufen. Ich glaube das hatte er gemeint.
Zitat von
nenad
Ich finde die Mails an UPC sehr amüsant, wie sollte den UPC beinflussen wie der Traffic von OVH an euch zurückgesendet wird?
Wo steht, dass das verlangt wird?
Zitat von
nenad
Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
IP Transit? Um aus einem Netz A (UPC) in ein Netz B (OVH) zu kommen, soll OVH IP Transit bei UPC kaufen? Möchtest Du das nicht nochmal überdenken? IP Transit kaufe ich, wenn ich durch ein Netz durch will, nicht, wenn ich direkt etwas "von" einem Netz will.
Damit auch Du heute Nacht gut schlafen kannst:
Transit is distinct from peering, in which only traffic between the two ISPs and their downstream customers is exchanged and neither ISP can see upstream routes over the peering connection.
Zitat von
nenad
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Deine Transit-Aussage disqualifiziert Dich von diesem Vorschlag.
Zitat von
nenad
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an
Na und? Um den geht es hier aber nicht. Mein Förmchen ist auch viel schöner als Deins.
Gruß, Klaus
Ich finde die Mails an UPC sehr amüsant, wie sollte den UPC beinflussen wie der Traffic von OVH an euch zurückgesendet wird?
Es liegt einzig und alleine an OVH wie die Pakete zurückgeroutet werden und wenn OVH keine gute Route zu UPC hat, müssen die Franzosen versuchen manuell Routen zu setzen (sofern die das Wissen dazu haben oder 50 eur für das Buch Routing for Dummies investieren dürfen...) welche bevorzugt für AS6830 genutzt werden, falls dies keine Besserung bringt einen Upstream Provider finden welcher eine gute Anbindung bietet oder direkt bei UPC IP Transit kaufen....
Aber Leute hört doch auf der UPC sonen Mist zu schreiben.... Ich komme nochmals an meinen Vorschlag zurück, die Option Premium Traffic einführen da soll dann halt UPC Upstream, Level3, Tata, D-Telekom, Verzizon ... mit hoher Priorität zur Verfügung stehen....
Nebenbei sowas bietet Bandbreitenmässig der grösste Hoster Europas (in NL zu hause) bereits seit Jahren an.... wobei dieser zu allen ISP top angebunden ist.... liegt daran das zahlreiche Video- und Filesharing Portale dort gehostet werden und da hat jeder ISP Freude daran
So hab jetzt nochmal getestet und das mit verschiedenen Root Anbietern und meiner Homeleitung (100mbit)... Tests wurden mehrmals am Tag wiederholt -->
strato - 11,7 MB Download
leaseweb - 11,4 MB Download
hetzner - 11,5 MB Download
host europe - 10,9 MB Download
1&1 - 11,6 MB Download
euserv - 11,8 MB Download
worldstream - 11,2 MB Download
OVH - 0,9 MB Download (und das maximal)
NUR bei OVH klappt der Speed nicht....
Zu mehr Servern hab ich leider keinen Zugang, aber das Ergebnis spricht ja für sich...
Und dabei waren da einige Roots dabei die wesentlich weiter entfernt sind als die in Frankreich.....
MFG
dieleitung is symetrisch und synct mir 18mbit, nachts bekomm ich die von einem privatem server... gebe euch nächste woche mal tracerts durch...
Zitat von
tester
ich sitze hier hinter einer buisness leitung von upc...
bekomme zu einem privatem server full speed 18mbit
hat jemand eine ip zum tracen ?
lg
18MB geht ja garnicht mit ner 100er Leitung?
Woher kommst du denn, Wien?
Btw wo steht denn der Server? Gibt ja nur Probleme zu OVH.
MFG
Edit: Ach grad gelesen sind ja nur 18mbit ^^ verlesen sorry
ich sitze hier hinter einer buisness leitung von upc...
bekomme zu einem privatem server full speed 18mbit
hat jemand eine ip zum tracen ?
lg
ich inodekunde tochter upc hänge somit im upc netz mit xdsl entbündelter leitung
und kann dies immo nur mehr via ftp auf ftp.ovh.net testen mit dem 100mb file
und ich erhalte 300 kib/s voon möglichen 2mbit
mehr kann ich leider nicht testen mehr - da ich keinen server mehr habe
Alles klar, wenn du noch was brauchen solltest lass ich dir gern meine Mail zukommen.
MFG
Zitat von
UPCUser
@Caddy
Du kannst mir gern ne IP schicken auf die ich ein Tracert machen soll.
MFG
Derweil habe ich keine, die ich öffentlich posten könnte. Macht aber nichts, ich habe UPC eben geantwortet und ein Traceroute auf eine betroffene IP Deines Subnetzes geschickt und dort auch geschrieben, dass das Problem ab einem bestimmten Hop auftritt (nämlich genau beim OVH/UPC Übergang). Ich denke, man wird sich melden, wenn das zu wenig Infos sind, dann müssen wir uns mal irgendwie austauschen.
Gruß, Klaus
@Caddy
Du kannst mir gern ne IP schicken auf die ich ein Tracert machen soll.
MFG
Zitat von
Caddy
(eigentlich sollte sowas ja koordiniert zwischen den Beteiligten geschehen, wer weiß, wo die da rumschrauben, wenn sie nicht miteinander sprechen)...
Eine Verschlechterung seitens UPC ist wohl kaum zu erwarten.
Und im Januar wird eh' alles anders
Zitat von
UPCUser
Hier bei mir (WIEN) IP 62.178.***.*** hat sich nichts geändert.. Ping schlecht Speed schlecht
MFG
Edit: Von nem Proof OVH --> Download startet mit 3MB´s und fällt innerhalb von Sekunden auf 200-400kbs ab...
Von nem Kimsufi noch schlechter --> Down startet mit 2,5MB´s und fällt innerhalb Sekunden auf 150-300kbs.
Hab ich schon fast befürchtet. Kannst Du mal ein traceroute zu einem kimsufi machen? Wenn irgendwie möglich zu einem in Roubaix 1, wenn ich schon die Möglichkeit habe und UPC so nett nachfragt, würde ich gerne die Nachfrage von UPC nutzen, falls Felix / OVH mich nicht stoppt :-) (eigentlich sollte sowas ja koordiniert zwischen den Beteiligten geschehen, wer weiß, wo die da rumschrauben, wenn sie nicht miteinander sprechen)...
LG, Klaus
Hier bei mir (WIEN) IP 62.178.***.*** hat sich nichts geändert.. Ping schlecht Speed schlecht
MFG
Edit: Von nem Proof OVH --> Download startet mit 3MB´s und fällt innerhalb von Sekunden auf 200-400kbs ab...
Von nem Kimsufi noch schlechter --> Down startet mit 2,5MB´s und fällt innerhalb Sekunden auf 150-300kbs.
Es gibt etwas Neues.
UPC hat mir geantwortet und angeblich etwas geändert. Das gilt vermutlich aber nur für Wien. Es müsste nun nochmal jemand testen, der definitiv noch über die alte Rückroute geht (die Netze hatte ich weiter oben beschrieben) Von meinem UPC Kontakt im 15. Bezirk habe ich mir gerade noch mal die Route von ihm zum Server schicken lassen, die hat sich allerdings nicht verändert. Für diejenigen, die es interessiert, hänge ich den kurzen Schriftverkehr um ein paar persönliche Details gekürzt nachfolgend an.
Gruß, Klaus
Meine Anfrage:
Gesendet: Montag, 19. November 2012 10:51
An: UPC Wien (Mailadresse entfernt)
Betreff: Technische Anfrage: Übertragungsgeschwindigkeiten UPC / OVH
Sehr geehrte Damen und Herren,
ich bin mir nicht sicher, ob diese eher technische Anfrage bei Ihnen unter dieser Mail-Adresse richtig platziert ist, falls nicht, wäre es nett, wenn Sie mir die richtige Adresse nennen, oder die Anfrage entsprechend weiterleiten. Es geht hier um sehr niedrige Übertragungsgeschwindigkeiten Ihrer Internetkunden zum Hosting-Anbieter OVH.
Als Betreiber (Details entfernt) haben wir in der letzten Zeit vermehrt Anfragen von UPC Kunden aus Wien, bei denen sehr niedrige Übertragungsgeschwindigkeiten zu und von unseren Servern die Nutzung stark beeinträchtigen.
Unsere Server stehen beim Anbieter OVH in Frankreich, mit dem wir eigentlich sonst keine Probleme dieser Art haben.
Wir stehen nun bereits in Kontakt mit OVH, wobei dort berichtet wird, dass sich das Thema nicht gerade einfach gestaltet. Details dazu gab es bisher nicht, da sich das Problem aber bereits über mehrere Monate erstreckt, möchten wir auf diesem Wege einmal direkt bei Ihnen anfragen.
Wir stehen auch in Kontakt mit einem UPC Kunden im 15. Bezirk, mit dem wir mehrfach ein paar Tests durchgeführt haben. In der Hauptzeit (ca. 18 bis 23 Uhr) bekommt dieser Kunde mit einer 100Mbit/s Leitung von UPC im Höchstfall ca. 1 Mbit/s Downloadgeschwindigkeit von unseren Servern bei OVH. Tests zu anderen Hostingabnietern in Deutschland zur gleichen Zeit zeigen Geschwindigkeiten von 50 Mbit/s und mehr, was durchaus akzeptabel ist.
Es gibt dazu ein Thema im deutschen Forum des Anbieters OVH, dessen Verlauf Sie hier einsehen können:
http://forum.ovh.de/showthread.php?t=11404
Das Thema wurde schon fast 5000 Mal gelesen, was auch ein erhebliches Interesse aufzeigt.
OVH bietet auch einen eigenen Speedtest an, den Sie hier
finden:
http://proof.ovh.net/
Ich würde mich sehr über eine Antwort freuen.
Mit freundlichen Grüßen
(ich)
Antwort von UPC:
Tue, 4 Dec 2012 14:16:24 +0000
Sehr geehrter Herr (ich),
vielen Dank, dass Sie uns kontaktiert haben.
Unsere zuständige Abteilung hat die Routingeinträge angepasst.
Verzeichnen Sie noch immer Performanceeinbußen aus dem Bereich Wien?
Die Frage (auch an Felix bzw. OVH) ist natürlich (ich habe eine direkte Antwortadresse von UPC bekommen und natürlich auch den Namen des Bearbeiters) ob es eher kontraproduktiv ist, wenn ich dort einfach mal weiter bohre, falls die Änderungen (wobei ich vom Routing her von UPC nach OVH keine Änderung sehe) nichts gebracht haben, oder ob ich's lieber lasse :-)
LG, Klaus
Moment, ist das nicht andersrum ?
Ein Trace vom Server zu UPC geht direkt - von UPC zu OVH geht über Telia.
Oder habe ich da was falsch verstanden ?
Ich habe eine Idee.... OVH könnte die Option "UPC Upstream" bieten, wenn man diese bucht kommt man in den Genuss eines direkten Routings in's UPC Netz
NB: Solange OVH bei UPC keinen IP Transit einkauft ändert sich da nichts gross.....
Zitat von
Darky68
und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend
@strex vielleicht kannst du die frage einem laien beantworten ovh und upc können es nicht
Wie soll er die Frage beantworten, man kann hier als Außenstehender nur Vermutungen anstellen. Wenn man dabei aber mal die Fakten zusammenzählt, deutet es schon darauf hin, dass das Problem bei UPC liegt, denn:
- Das Peering in die Schweiz nach UPC verhält sich EXAKT genau so. Die gleichen schlechten Übertragungsraten, der selbe Packet Loss.
- Zig andere Peerings von OVH verhalten sich völlig korrekt und haben diese Probleme nicht
- UPC antwortet mir als Außenstehender auf Anfragen überhaupt nicht. Klar, wer bin ich auch, ich bin ja kein UPC Kunde. (Die Vermutung stimmt nicht, denn ich bin Unitymedia Kunde. Unitymedia gehört Liberty Global, UPC gehört ebenfalls Liberty Global).
- Andere Probleme (Auslastungsprobleme, die ganz klar bei OVH liegen / lagen) werden von OVH erkannt und behoben.
Da mutmaßt man ja schon, dass das Problem wohl eher bei UPC liegt.
Wenn man dann noch mal etwas tiefer ins Netz schaut und findet zig Artikel, die mutmaßen, dass UPC den Traffic manchmal und zu diversen Zielen limitiert, da macht man sich schon seine Gedanken.
Wir als "Endverbraucher" werden vermutlich auch immer die Antwort bekommen, dass jeweils die andere Seite das Problem ist. Das Problem kann nur auf technischer Ebene direkt zwischen OVH und UPC geklärt werden. Das läuft ja bereits, wie Felix auch schon schrieb ("Wir sind dran", "Es ist nicht einfach").
Gruß, Klaus
Zitat von
UPCUser
Zu nem Speedtest werden meist mehrere Verbindungen gleichzeitig aufgebaut, wenn du mit FTP was lädst dann nur mit einer Verbindung.
Wobei ich komme beim Speedtest nicht über 2mbit mit meiner 100mbit Leitung
Also mir kommt es vor als würde da jemand absichtlich drosseln (ws eh UPC)
zur info ich probier beides mit ftp prog filezilla client
fazit müsste wenn alles ok ist - bei beiden testservern ein 100mbit file bei mir maximal 2mbit rüber kommen
was A nur bei einem passiert und B beim ovh server eben nicht nur wie gesagt immer schwankend schlechtester wert in 2wochen 70 besster wert in 2wochen 300
Zitat von
Darky68
jetzt ist meine frage warum bekomme ich vollen speed 2mbit zb von einem testserver speedtest.qsc.de wenn ich ein 100mb grosses testfile lade
und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend
Zu nem Speedtest werden meist mehrere Verbindungen gleichzeitig aufgebaut, wenn du mit FTP was lädst dann nur mit einer Verbindung.
Wobei ich komme beim Speedtest nicht über 2mbit mit meiner 100mbit Leitung
Also mir kommt es vor als würde da jemand absichtlich drosseln (ws eh UPC)
Zitat von
UPCUser
Laut UPC Service Techniker und auch der Businesshotline stimmen die Auslastungen auf der Weathermap nicht und mir wurde empfohlen mich an OVH zu wenden da der Fehler nicht am UPC Netz liegen soll.
Angeblich ist irgend ein langsamer Switch dazwischen or what ever ich kenn mich da auch nicht so aus damit.
War mit denen in Kontakt mit mehreren "Beweis Tracings" etc ,...
Und ja ich weis wenn ich nochmal anrufe sagt mir ein andrer Techniker wieder was ganz andres.
Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.
MFG
das kann ich mit guten gewissen unterschreiben - wiegesagt bin inode kunde aus wien und habe wie schon beschrieben das gleiche problem
weiters wurde mir auch von inode und upc gesagt das sie hier keine probleme haben und man möge sich an ovh wenden, denn wenn man auf einen anderen server in deutschland zumt esten geht funktioniert alles einwandfrei, kommt man auf einen ovh server ist schluss damit
jetzt ist meine frage warum bekomme ich vollen speed 2mbit zb von einem testserver speedtest.qsc.de wenn ich ein 100mb grosses testfile lade
und warum bekomme ich vom ftp.ovh.net server (fazit ein ovh server) nur noch 70-300 schwankend
@strex vielleicht kannst du die frage einem laien beantworten ovh und upc können es nicht
klar das inode/upc sagen liegt nicht an uns - aber an wem liegt es dann wenn jetzt nicht an ovh oder irgendeinen lahmen router switch im netz
Ich hab ja nicht gedroht, mir bleibt leider nix andres übrig... Ich muss jeden Tag mehrere GB an Daten Up und Downloaden und wenn ich leider nur 1Mbit erreiche geht das so leider nicht.
Klar hätte ich es auch freundlicher ausdrücken können, aber ich werd von UPC hierher verwiesen und hier heissts ich soll bei UPC fragen.
Und das es ja besser geht sieht man ja da andre User jetz Vollspeed haben. Habe diesbezüglich auch bei UPC schon angefragt ob sie mir nicht einfach eine andre IP geben können auf der das Tata Routing läuft, das machen sie aber mit der Begründung nicht das diese Statische IPs sind.
Deshalb hatte ich ja drauf gehofft das es OVH hinkriegt wenn UPC eben nicht will, nur schade das es eben nicht bei allen UPC Usern geht. Jetzt sind wir faktisch zweigespalten...der eine voll der andre nix.
Zitat von
UPCUser
Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.
MFG
Das wurde sicher schon lange getan. Das braucht eben seine Zeit. Als das selbe Spiel mit der Telekom war, hat das durchaus fast ein Jahre gedauert. Ihr seit also noch gut dran. Bis Januar ist ja nicht mehr lange, warum ist das denn nicht hinnehmbar, dass man mit Kündigung droht?
Laut UPC Service Techniker und auch der Businesshotline stimmen die Auslastungen auf der Weathermap nicht und mir wurde empfohlen mich an OVH zu wenden da der Fehler nicht am UPC Netz liegen soll.
Angeblich ist irgend ein langsamer Switch dazwischen or what ever ich kenn mich da auch nicht so aus damit.
War mit denen in Kontakt mit mehreren "Beweis Tracings" etc ,...
Und ja ich weis wenn ich nochmal anrufe sagt mir ein andrer Techniker wieder was ganz andres.
Darum wär es ja das beste wie schon von mir geschrieben das sich OVH mit UPC in Verbindung setzt, denn als normaler User hat man da anscheinend eh keine Chance.
MFG
Zitat von
UPCUser
Erstmal hab ich nie gesagt das ich einen Isgenug hab, zweitens wer sagt dir das es nur ein Root ist?
Auch wenn es 10 oder 100 sind, dass würde die Kosten für das Peering mit UPC bei weitem nicht decken.
Zitat von
UPCUser
Und ich hab auch NICHT behaupted das OVH schuld ist.
Da lesen deine Beiträge sich aber ganz schön anders, du forderst von OVH das es schnell liegt und jammerst wenn das nicht möglich ist. Hast du schon so viel Kommunikation mit UPC betrieben. Ich glaube nicht..
Zitat von
UPCUser
Und wenn du schon von Niveau redest solltest dir mal deine eigenen Postings durchlesen, denn statt Lösungsvorschläge oder dergleichen vorzuschlagen postest du so gut wie überall nur Schwachsinn dazu den eh keinen interessiert oder nichts mit dem Thema zu tun hat.
Meine Posting sind meist sehr hilfreich, sonst wären das nicht schon 1600 Stück. Nur das ewige Gejammere und die Forderung bringen ab und zu auch einmal in paar nette Kommentare um die User, wie auch dich, wieder auf den Boden der Tatsachen herunterzuholen. Dir reicht nicht der Januar, alles soll sofort zur Verfügung stehen, sind wir im Wunschparadis? Dann will ich auch was Du forderst und drohst mit Kündigung, konstruktiv nenne ich was anderes, wenn ich da meine Postings mit deinen vergleiche, hmm, wer hat da wohl mehr Niveau?
Zitat von
UPCUser
Du hast ws den ganzen Tag nichts besseres zu tun als Leute zu beleidigen oder zu nerven.
Selbst wenn du persönlich gegen mich was haben solltest, was hat das jetzt mit dem Thema hier zu tun ?!
Ich habe hier noch keinen Beleidigt, so etwas verbitte ich mir! Alles was ich geschrieben habe, war konstruktiv und korrekt. Beleidigen tuen hier nur andere
Zitat von
UPCUser
Übrigens garantiert OVH natürlich nicht den vollen Speed, das macht kein Provider, jedoch kann ich mich dunkel erinnern das 90mbit garantiert sind.
Garantiert bis nach Hause ist gar nichts, auch keine 90 Mbit/s oder eine andere Bandbreite. OVH hat nur Kontrolle über das eigene Netz, sobald die Pakete dies verlassen haben ist eine Kontrolle nicht mehr möglich. Das wäre aber für eine Garantie von Nöten.
Zitat von
UPCUser
Und die sollten auch mit meiner UPC 100mbit Leitung abrufbar sein.
Und selbst wenn die nicht garantiert sind erreiche ich nur 1 !! MBIT.... und zwischen 100 und 1 ist aber schon n Unterschied denkst du nicht?
Warum sollten die abrufbar sein? Wer sagt oder garantiert dir das? Keiner! Ich erhalten von meinem Handy, aus China oder Afrika auch nicht die volle Bandbreite? Erstelle ich dafür zig Threads und Postings und fordere garantierte Bandbreite nach China. Nein das tue ich nicht, auch wenn die Bandbreite aus China und Afrika durchaus noch schlechter sind. Wer etwas technisches Verständnis für Netzinfrastruktur hat, weiß auch warum das nicht möglich ist.
Zitat von
UPCUser
UPC hat hier bei uns eben eine Monopolstellung und da hat man eben nicht die große Auswahl, schon garnicht wenn man anständigen Speed möchte.
Wie man sieht, bringt UPC zu einigen Ziele nicht besonders viel Speed. Vielleicht ein anderer, bestimmt! Dann musst du auch mit dem Speed leben und nicht jeden Tag weitere Postings verfassen. Was soll das bringen, du drohst ja ständig mit einer Kündigung, dann setze auch einmal deine Worte in Taten um. Das wäre wohl für dich und OVH das Beste.
Zitat von
UPCUser
Also nochmal extra für dich --> Mir egal wer schuld ist, ob OVH oder UPC, es muss sich nur was ändern da eben besagte UPC User im Moment nichts anfangen mit nem Root von OVH.
Wenn dir egal ist wer Schuld hat, wende dich an die UPC oder such dir einen anderen Serverhost. Wenn Felix es sagt es ist nicht möglich, ist es nicht möglich. Was soll man da weiter diskutieren und jammern. Genau, das bringt nix! Die Lösungen wurden dir aufgezeigt, jammern bringt nichts, also bis du am Zug etwas zu unternehmen.
Erstmal hab ich nie gesagt das ich einen Isgenug hab, zweitens wer sagt dir das es nur ein Root ist?
Stimmt schon das wegn ein paar Roots OVH nicht untergeht, ich hab auch nur gesagt das man als UPC User im Moment OVH nicht ordentlich nutzen kann...
Und ich hab auch NICHT behaupted das OVH schuld ist.
Und wenn du schon von Niveau redest solltest dir mal deine eigenen Postings durchlesen, denn statt Lösungsvorschläge oder dergleichen vorzuschlagen postest du so gut wie überall nur Schwachsinn dazu den eh keinen interessiert oder nichts mit dem Thema zu tun hat.
Du hast ws den ganzen Tag nichts besseres zu tun als Leute zu beleidigen oder zu nerven.
Selbst wenn du persönlich gegen mich was haben solltest, was hat das jetzt mit dem Thema hier zu tun ?!
Übrigens garantiert OVH natürlich nicht den vollen Speed, das macht kein Provider, jedoch kann ich mich dunkel erinnern das 90mbit garantiert sind.
Und die sollten auch mit meiner UPC 100mbit Leitung abrufbar sein.
Und selbst wenn die nicht garantiert sind erreiche ich nur 1 !! MBIT.... und zwischen 100 und 1 ist aber schon n Unterschied denkst du nicht?
UPC hat hier bei uns eben eine Monopolstellung und da hat man eben nicht die große Auswahl, schon garnicht wenn man anständigen Speed möchte.
Also nochmal extra für dich --> Mir egal wer schuld ist, ob OVH oder UPC, es muss sich nur was ändern da eben besagte UPC User im Moment nichts anfangen mit nem Root von OVH.
Zitat von
UPCUser
Und wenn ich nen 100mbit Root habe will ich auch 100 Mbit nutzen können und nicht nur 1!!MBIT.... Ich kauf mir auch keinen Porsche mit 50 PS...
Dir garantiert keiner (Kein Serveranbieter der Welt), dass du Fullspeed bis nach Hause bekommst. Es wird der lediglich 100 Mbit/s am Switchport gegeben. Ich krieg ja auch nicht 1000 Mbit/s nach Hause, der Root kann es, wenn meine Leitung nur 50 Mbit/s ermöglicht. Ich will ja volle Leistung...
Der Autovergleich ist ja auch voll daneben, wie fast alle Aussagen von dir. Eher kannst du den Porsche nicht voll ausfahren, weil die Geschwindigkeit begrenzt ist. Kann dafür der Hersteller etwas? Genau, nein der ist nicht verantwortlich.
Zitat von
UPCUser
Auf alle Fälle können UPC User im Moment nichts mit OVH anfangen da man ja dann nicht weis welchen Speed man bekommt...
Drehen wir doch die Geschichte um, mit UPC kann man nichts anfangen..Dann solltest du den Anbieter wechseln. Bitte mach deine Drohung war und verlass uns, wegen dem einen Isgenug, geht OVH schon nicht unter. Dann ist hier endlich wieder ein richtiges Niveau vorhanden.
Nun ich weis das es nurnoch 8 Wochen sind bis Jänner, nur wer garantiert mir das diese Lösung dann funktioniert? Im Moment haben UPC User lahmen Speed und andre UPC User bekommen den maximalen.... das ist doch irgendwie nicht in Ordnung, egal ob es jetzt an OVH oder UPC liegt.... Ok OVH hat etwas dagegen getan und ein paar UPC User auf Tata geroutet, aber von einer Lösung ist das weit entfernt.
Wenn jetzt jemand aus Wien bei OVH einen Root mietet dann wird es zum Glücksspiel ob er nun lahmen oder vollen Speed bekommt....
Das ist doch nicht Sinn der Sache oder?
Und wenn ich nen 100mbit Root habe will ich auch 100 Mbit nutzen können und nicht nur 1!!MBIT.... Ich kauf mir auch keinen Porsche mit 50 PS...
Ja das Peering auf der Weathermap sieht leer aus, na und es geht trotzdem nichts weiter und alles ist lahm... Was hab ich davon wenn die Auslastung bei 0% liegt und ich keinen Speed bekomme? Da ist mir lieber es wird 80% angezeigt und dafür geht was weiter..
Auf alle Fälle können UPC User im Moment nichts mit OVH anfangen da man ja dann nicht weis welchen Speed man bekommt...
Zitat von
UPCUser
Na toll.... dann bin ich der nächste der bei OVH kündigt.
Naja, wenn wir mal ehrlich sind, zieht sich das eigentliche Problem ja schon mehrere Monate hin. Ich weiß ja nicht, wie lange Du schon bei OVH bist, wenn wir von einer Lösung bis Ende Januar ausgehen, sind das noch ca. 8 Wochen. Ich bin zwar persönlich bei diesem Problem nahezu unbetroffen, lediglich einer unserer Gameserver Admins kommt aus Wien und ein paar Spieler. Wir würden aber dafür nicht den Anbieter wechseln. Mit dem Peering der restlichen Netze bin ich zufrieden und ich liebe die Transparenz von OVH.
Bemerkenswert in dieser Angelegenheit ist auch, dass ich am 19.11.2012 UPC in dieser Angelegenheit einmal ganz unverbindlich angeschrieben habe, es gab bis heute weder irgend eine Rückmeldung, noch sonst irgendein Lebenszeichen.
Gruß, Klaus
http://weathermap.ovh.net/wien
nuja, die Leitung ist aber nunmal ziemlich leer. Nicht zuletzt da jetzt der Großteil der User über TATA geht. (Warum das für die restlichen nicht ohne weiteres geht muss Felix mal detaillierter erklären wenn es ihm möglich ist, das ist mir auch nicht ganz klar).
Allerdings: Ne ohnehin leere Leitung in die Richtung zu drosseln erscheint mir reichlich widersinnig.
Und UPC hat in Sachen Peering Policy nunmal seinen Ruf weg, der schwarze Peter/Beweislast mangels Transparenz seh ich in dem Fall nicht zuletzt dank der offen einsehbaren Weathermap hier erstmal bei UPC , auch wenn das hier natürlich das OVH Forum ist.
Zitat von
kenshin
Dein Speed ist trotzdem scheisse. Könnte es eventuell an UPC liegen? Nie nicht.
ist nicht nur chello von upc
ist ja entbündelte telefonleitung xdsl von inode das gleiche
und laut inode (tochter von upc) wird nichts gedrosselt man soll sich mit ovh in verbindung setzen
ovh sagt dann upc
da wird man wie ein squashball hin und her geschickt
warum setzt sich ovh nicht mal mit inode in verbindung bzw auch mit upc und klärt das von firma zu firma
Zitat von
UPCUser
Na toll.... dann bin ich der nächste der bei OVH kündigt.
Bis Jänner warte ich nicht da such ich mir einen andren Hoster.
Mir ist nicht ganz klar warum bereits andere UPC User über Tata gehn aber für die restlichen das nicht möglich sein soll....
Ok das wars für mich hier
So long... MFG
also: du hast aktuell ne leere Leitung zwischen OVH und deinem ISP. OVH drosselt nichts laut Felix und Bandbreite ist auch genug da.
Dein Speed ist trotzdem scheisse. Könnte es eventuell an UPC liegen? Nie nicht.
Schade das ein OVH Kunde nach dem anderen geht... da bei mir vorerst der Speed in Ordnung ist werd ich wohl nicht kündigen und mal 3 Monate verlängern.
Zitat von
Felix
Das ist momentan leider nicht möglich.
Na toll.... dann bin ich der nächste der bei OVH kündigt.
Bis Jänner warte ich nicht da such ich mir einen andren Hoster.
Mir ist nicht ganz klar warum bereits andere UPC User über Tata gehn aber für die restlichen das nicht möglich sein soll....
Ok das wars für mich hier
So long... MFG
Zitat von
Caddy
Die Frage ist ja nun, ob es noch möglich ist (zumindest bis im Januar eine Lösung in Sicht ist), die verbliebenen Subnets ebenfalls über TATA zu routen.
Das ist momentan leider nicht möglich.
Zitat von
Felix
Das Peering mit UPC in Wien ist nun fast leer, es gibt von unserer Seite keinerlei Restriktionen, Überlastungen oder sonstiges. Wir vermuten das seitens UPC gedrosselt wird.
Wie auch immer und was auch immer dafür sorgt, dass auf dem alten Peering selbst dann, wenn es leer ist, alles total langsam ist - Das Problem aus der "Nutzer Sicht" ist ja derzeit, dass alles, was ihr an UPC Netzen derzeit über TATA routet, "Fullspeed" gibt, alles was noch auf dem alten Wiener Peering liegt, langsam ist. Ihr habt ja jetzt unbewusst eine 2-Klassen Gesellschaft geschaffen:
- UPC User, die auf dem alten Peering verblieben sind (langsam)
- UPC User, die über TATA routen (schnell)
Die Leute wohnen teilweise nur ein paar Straßen vonenander entfernt. Bei UPC bzw. speziell bei Chello (ehemals Telekabel Wien) haben die Nutzer quasi eine statische IP-Adresse - Sie ändert sich (manchmal) nur, wenn man das Kabelmodem wechseln lässt.
Die Frage ist ja nun, ob es noch möglich ist (zumindest bis im Januar eine Lösung in Sicht ist), die verbliebenen Subnets ebenfalls über TATA zu routen.
Gruß, Klaus
Zitat von
UPCUser
Das Peering mit UPC in Wien ist nun fast leer, es gibt von unserer Seite keinerlei Restriktionen, Überlastungen oder sonstiges. Wir vermuten das seitens UPC gedrosselt wird.
Tut sich hier noch was ?
Ich hab nach wie vor lahmen Speed :/ und die Route läuft immer noch nicht über Tata mit meiner IP.
MFG
Sorry ja hattest recht IP ist 62.178.255.**** und da geht nach wie vor nicht viel.... Bitte nochmal ransetzen OVH.
Danke für die Mühe
Edit: Zu nem Proof OVH schaff ich 1MB UP und zu nem Kimsufi nur zwischen 50-150kbs.... Das ne Katastrophe, bitte kriegt das noch hin.
Edit2: Hab jetzt auch mal ein Tracert zu OVH gemacht mit dem Ergebnis das es ständig Packetlos gibt und hier nicht über Tata geroutet wird. (also immer noch die alte Route verwendet wird)
IP 62.178.255.***
Zitat von
UPCUser
Meine IP bei UPC ist 162.178.****** und der Speed ist zwar besser aber noch nicht das gelbe vom Ei.
Bist Du sicher mit der IP? Laut RIPE könnte es eher 62.178.x.x sein:
http://bit.ly/Qvljbm
Dieses Netz geht übrigens auch noch über die alte Route:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. rbx-6-m1.fr.eu 0.0% 9 0.8 0.8 0.4 1.4 0.2
2. rbx-2-6k.fr.eu 11.1% 9 0.3 0.7 0.3 1.9 0.6
3. rbx-g2-a9.fr.eu 0.0% 9 0.8 10.6 0.7 88.6 29.2
4. fra-5-6k.fr.eu 87.5% 9 8.1 8.1 8.1 8.1 0.0
5. pra-1-6k.cz.eu 0.0% 9 16.3 48.8 16.1 164.9 64.6
6. vie-1-6k.at.eu 0.0% 8 20.9 22.9 20.7 37.3 5.8
7. upc.as6830.at.eu 0.0% 8 26.3 26.4 26.3 26.6 0.1
8. at-vie01a-ra3-ge-0-1-0.aorta.net 0.0% 8 21.8 26.3 21.4 50.9 10.1
9. at-vie-sk11-pe01-vl-2042.upc.at 0.0% 8 26.7 29.0 26.7 43.8 6.0
10. chello062178XXXXXX.4.11.vie.surfer.at 0.0% 8 21.9 21.8 21.5 22.7 0.4
Ob die vielleicht vergessen wurden, dazu kann nur Felix was sagen. Wenn dem so ist, wäre auch klar, warum es bei euch noch langsam ist.
Gruß, Klaus
Zitat von
Darky68
jetzt stellt sich noch eine frage für mich - wenn ich provider wechsel zb zu telekom hab ich da die gleichen probleme?????
nein.
Meine IP bei UPC ist 162.178.****** und der Speed ist zwar besser aber noch nicht das gelbe vom Ei. Download mit einem Stream schwankt zwischen 300kbs und 2 MB... Der Upload mit einem Stream zwischen 300kbs und 1MB.
Grade auf den UPLOAD wär ich angewiesen das der stabil ist. Und mehr als ein Stream ist nicht möglich bei mir.
MFG
Zitat von
Felix
Wie genau äussern sich denn Probleme bei diesen IP-Ranges?
Die Route vom Server zu meinem UPC Kunden, der richtig Speed bekommt:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. rbx-6-m1.fr.eu 0.0% 74 0.7 1.1 0.5 26.4 3.1
2. rbx-2-6k.fr.eu 27.4% 74 0.4 4.5 0.2 121.2 18.8
3. rbx-g2-a9.fr.eu 0.0% 74 0.7 12.9 0.5 344.8 53.5
4. fra-5-6k.fr.eu 33.8% 74 7.9 9.1 7.9 51.5 6.4
5. tata.as6453.de.eu 0.0% 74 18.4 12.7 8.0 21.4 4.4
6. if-4-1108.tcore1.FNM-Frankfurt.as6453.net 0.0% 74 8.3 9.1 8.0 60.3 6.2
7. if-5-2.tcore1.AV2-Amsterdam.as6453.net 0.0% 74 10.7 12.1 10.3 41.1 5.3
8. if-2-2.tcore2.AV2-Amsterdam.as6453.net 0.0% 74 10.3 11.0 9.9 60.0 5.8
9. 80.231.152.22 0.0% 74 14.7 14.6 14.2 17.7 0.5
10. nl-ams05a-rd2-xe-4-2-2.aorta.net 2.7% 74 28.4 28.9 27.8 59.8 4.0
11. at-vie01a-rd1-xe-0-2-0.aorta.net 5.5% 73 33.3 36.0 33.1 76.8 7.5
12. at-vie-sk11-pe01-vl-2042.upc.at 2.7% 73 33.2 36.4 32.9 117.6 12.4
13. at-vie-sk11-pe02-vl-1.upc.at 2.7% 73 27.9 30.1 27.8 56.8 6.7
14. ???
15. chello213047xxxxxx.20.11.vie.surfer.at 0.0% 73 40.8 44.4 39.7 70.4 4.9
Die IP des Kunden liegt im 213.47.x.x Bereich und wird von unserem Server in Roubaix 1 über TATA geroutet.
Die beiden Netze, die ich oben beschrieben habe sind ebenfalls UPC Vienna und routen den Weg:
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. rbx-6-m1.fr.eu 0.0% 11 0.6 0.7 0.5 1.0 0.1
2. rbx-2-6k.fr.eu 0.0% 11 2.3 1.8 0.3 14.5 4.3
3. rbx-g2-a9.fr.eu 0.0% 11 0.9 36.9 0.8 396.1 119.1
4. fra-5-6k.fr.eu 27.3% 11 8.4 8.1 7.9 8.4 0.2
5. pra-1-6k.cz.eu 0.0% 11 16.0 16.1 16.0 16.3 0.1
6. vie-1-6k.at.eu 0.0% 11 20.7 20.8 20.6 21.5 0.3
7. upc.as6830.at.eu 0.0% 10 26.5 26.4 26.3 26.5 0.1
8. 213.46.173.126 0.0% 10 21.5 22.4 21.4 28.6 2.2
9. at-vie-sk11-pe02-vl-2043.upc.at 20.0% 10 22.9 22.5 22.2 23.0 0.3
10. at-vie-sk11-pe01-vl-1.upc.at 0.0% 10 26.9 29.3 26.9 50.0 7.3
11. ???
12. chello084112XXXXXX.23.11.vie.surfer.at 0.0% 10 30.0 29.2 27.8 30.9 1.0
Das ist die alte Route, die nicht über TATA geht. Die IP Blöcke tauchen im Posting von sting und Faultier auf, die auch beide noch den alten langsamen Speed haben ...
Gruß, Klaus
obwohl ich nur noch 2tage kunde bin da ja der speed zu ovh servern noch immer für mich im keller ist
kann ich euch nur sagen - das ich zum ftp.ovh.net server mit dem test.bin file
im schnitt nur 75-200kb/s schaffe - einzig heute früh um 9herum gings mal auf 500
ich bin inode kunde einem tochterunternehmen von upc
ich würde gern wieder einen server bei euch mieten aber erst wenn ihr zumindest eine bandbreite zu upc/inode von mindest 1.0mbit verischern könnt - alles darunter wäre unzumutar
ich würd mich über eine rückmeldung von ovh - wenn dies erreicht ist gern freuen - da ihr dann wieder einen kunden habt
Zitat von
Caddy
@Felix : Falls Du noch mit liest, ihr habt vermutlich ein paar Netzblöcke vergessen, zumindest den da:
inetnum: 80.108.148.0 - 80.109.127.255
Wie genau äussern sich denn Probleme bei diesen IP-Ranges?
Zitat von
sting
Kann mein UPC Kontakt in Wien so leider nicht bestätigen...
Tests @ proof.ovh.net:
Code:
IP Down (kb/s) Up (kb/s) Latency (ms)
80.109.39.xxx 11745 7209 69
80.109.39.xxx 12769 8160 68
80.109.39.xxx 10037 8615 68
Auslastung laut Weathermap (vie-3-f10): 49% und 56%
Speedtest.net:
http://www.speedtest.net/result/2320921019.png
@Felix : Falls Du noch mit liest, ihr habt vermutlich ein paar Netzblöcke vergessen, zumindest den da:
inetnum: 80.108.148.0 - 80.109.127.255
netname: CHELLO
descr: UPC Telekabel
route: 80.109.0.0/16
Das ist auch der Grund, warum vielleicht manche UPC Kunden noch Probleme haben. Leider kann man dort als UPC Kunde ja auch nicht so einfach seine IP wechseln ...
Gruß, Klaus
Edit: Den auch:
inetnum: 84.112.0.0 - 84.115.43.7
netname: CHELLO
descr: UPC Austria
route: 84.112.0.0/14
Gehen beide über die alte Route (upc.as6830.at.eu).
Edit2: Für die Weathermap Freaks - Wenn der Traffic über TATA geroutet wird, dann kann vie-3-f10 in Flammen stehen, darüber geht der Traffic gar nicht mehr :-)
Zitat von
faultier
bei mir UPC Wien:
84.114.63.xxx 41680 9081 32
Das sieht gut aus, ABER beim FTP geht nur 1400 kb/s im Moment, schwankend nach unten.
Früher hatte ich 4000 kb/s.
Aber wenn es vorerst mal so bleibt, damit kann ich mal leben.
Wenn du mit FTP arbeitest kannst du ja die gleichzeitigen Downloads erhöhen dann passt der Speed auch wieder.
Ich hatte das Problem das ich nur 1nen Stream habe, mehrere auch nicht möglich sind, und da kam ich nicht über 200kbs.
Ps.: Auch UPC Wien
bei mir UPC Wien:
84.114.63.xxx 41680 9081 32
Das sieht gut aus, ABER beim FTP geht nur 1400 kb/s im Moment, schwankend nach unten.
Früher hatte ich 4000 kb/s.
Aber wenn es vorerst mal so bleibt, damit kann ich mal leben.
Es geht auf alle Fälle mal besser als vorher. Die Auslastung lag sonst Rund um die Uhr bei 70-90% bei UPC Wien. Der Upload flutscht jetzt auch Richtung OVH Root. Der Down schwankt zwischen 2MB und 6 MB.... Bin zufrieden bis Januar wenn es so bleibt.... Auf alle Fälle nochmal ein dickes Danke für die Mühe... und bitte nicht wieder was zerbasteln
Kann mein UPC Kontakt in Wien so leider nicht bestätigen...
Tests @ proof.ovh.net:
Code:
IP Down (kb/s) Up (kb/s) Latency (ms)
80.109.39.xxx 11745 7209 69
80.109.39.xxx 12769 8160 68
80.109.39.xxx 10037 8615 68
Auslastung laut Weathermap (vie-3-f10): 49% und 56%
Speedtest.net:
http://www.speedtest.net/result/2320921019.png
Irgendwer hat doch heimlich den proof.ovh.net repariert :-)
Mein UPC Kontakt jubelt schon so laut, dass ich es fast hier in DE höre, die Speedtests vom proof.ovh.net liegen bei ihm jetzt durchgehend zwischen 40 und 80 Mbit/s.
Jetzt habe ich, neugierig wie ich bin, von mir (Unitymedia, NRW) auch nochmal getestet:
Last Result:
Download Speed: 112442 kbps (14055.3 KB/sec transfer rate)
Upload Speed: 5071 kbps (633.9 KB/sec transfer rate)
Latency: 32 ms
Dienstag, 20. November 2012 20:05:48
Für mich lege ich das erstmal als erledigt ab. Auch wenn die Pings abends hochgehen, der Durchsatz bleibt bisher. Ich hoffe dann, dass die "Januar" Lösung dann nochmal einen kleinen Latenzschub bringt.
Danke :-)
Gruß, Klaus
So, jetzt habe ich mal was recht verrücktes gebastelt. Ich habe noch einen V-Server bei einem Mitbewerber in Deutschland. Zu diesem habe ich von meiner Linux-Kiste zuhause einen OpenVPN gebaut und benutze ihn als Gateway. Weil ich zu faul bin in diesem Tunnel ein ordentliches Routing einzurichten habe ich noch zusätzlich 2 x NAT dazwischen. Der Windows-Rechner benutzt meine Linux-Kiste als Gateway. Nun bekomme ich 96 Mbit von proof.ovh.net und sogar 99 Mbit von meinem Server in Roubaix ;-)
Wenn selbst so eine Krüppelkonfiguration um diese Uhrzeit geht - tja dann werde ich mir wohl erstmal keine Sorgen mehr machen :-)
Direkt (UPC in der Nähe von Zürich) tröpfeln von proof.ovh.net so um die 3 Mbit durch, vom Server immerhin 4. Das war auch schonmal schlechter ...
download und ping sind aufjedenfall besser geworden !
10mbit/s durchschnittlich.
Also im Moment sieht es gut aus -->
http://www10.pic-upload.de/20.11.12/ejsmjwfqw93.jpg
Jedoch ist die Auslastung auf der Weathermap Wien gerade niedriger, ich trau mich wetten das heute Abend wieder nichts mehr durch die Leitung geht.
Wenn es so bleiben würde dann wär ich zufrieden und bleib bei OVH... Mal heute Nacht nochmal prüfen dann wirds wieder stauen
Also ich bin in Wien, UPC 100 mb Leitung, im Moment erreiche ich ca 900 -1100 kb/s. Viel besser geworden als in den letzten Tagen, normalerweise habe ich bis zu 4000 kb/s bei dem FTP Server.
Aber je länger es dauert, um so langsamer wird es. Jetzt nur noch 800 kb/s
Also ich habe mit meinem UPC Kontakt gerade nochmal getestet. Speedtests über proof.ovh.net bringen irgendwie nichts, das Ding ist ziemlich unzuverlässig. Wir haben nochmal einen Download direkt von unseren Servern gemacht. Es kommen von Roubaix 1 tx: 38.52 Mbit/s 3608 p/s (mit vnstat direkt auf dem Serverinterface gemessen, deckt sich auch mit der Angabe beim Testenden. So viel gab's schon lange nicht mehr.
Von einem anderen Server (Roubaix 3): tx: 61.15 Mbit/s 5457 p/s
Das "Testobjekt" sitzt im 15. Bezirk in Wien. Geschwindigkeit vor der Änderung: höchstens 1-2 Mbit/s.
Den Speedtest unter proof.ovh.net sollten wir wohl vergessen
Gruß, Klaus
Ja bei mir auch nach wie vor sehr starke Schwankungen von 20- 200kbs maximal...
Wenn sich bis Ende der Woche nix ändert werd ich wohl auch kündigen, Kann mir ja keiner zumuten nen 100mbit Root mit 200kbs zu nutzen.
über UPC in der Nähe von Zürich mit 100 Mbit-Anschluss:
Download Speed: 5556 kbps (694.5 KB/sec transfer rate)
Upload Speed: 4512 kbps (564 KB/sec transfer rate)
Latency: 34 ms
Mon Nov 19 23:00:11 2012
Ich glaube das war die letzten Tage aber immer so.
@ OVH Team
Erstmal vielen Dank das ihr euch so mühe gebt, und das auch noch so schnell. Normal sollte sich da ja UPC drum kümmern.
Erreiche beim Speedtest 200-300 kbs beim Down von nem Proof.OVH - Des weiteren zeigt die Weathermap UPC Wien ja auch gerade 87% auslastung. da geht ws nicht mehr.
Zitat von
Felix
OK, noch etwas Feintuning: Jetzt noch besser?
Last Result:
Download Speed: 2812 kbps (351.5 KB/sec transfer rate)
Upload Speed: 2640 kbps (330 KB/sec transfer rate)
Latency: 106 ms
Montag, 19. November 2012 19:29:39
von eurem Speedtest, Testdownload von unserem Server: zwischen 4 und 8 MBit/s, kein Packet Loss. Der Ping zu unserem Server (Roubaix 1) liegt auch recht gleichmäßig bei 45ms, bei eurem Speedtest deutlich höher. Vielleicht testet auch gerade Gott und die Welt :-)
Edit: Euren Speedtest nehme ich dann lieber nicht mehr. Der zeigt bei mir über Unitymedia folgendes:
Download Speed: 3562 kbps (445.3 KB/sec transfer rate)
Upload Speed: 4061 kbps (507.6 KB/sec transfer rate)
Latency: 27 ms
Von unserem Server bekomme ich aber Fullspeed ( ~98Mbit/s ) :-)
Ich habe meinen UPC Kontakt auch lieber von unserem Server downloaden lassen.
Gruß, Klaus
Zitat von
Felix
das bleibt jetzt erstmal so bis die bessere Lösung umgesetzt werden kann.
OK, noch etwas Feintuning: Jetzt noch besser?
Zitat von
Caddy
Beim Routing über TATA hatte sich vorher schon gezeigt, dass es zwar recht stabil ist, aber auch ziemlich Tageszeitabhängig... Wenn es geht, lasst es bitte erst mal so
Danke für die Rückmeldung! Ja, das bleibt jetzt erstmal so bis die bessere Lösung umgesetzt werden kann.
ich versteh nicht ganz warum ich bei proof.ovh 7,8mbit/s schaffe und zu meinem server nichtmal 3mbit/s (von möglichen max. 20mbit/s)
@Felix:
Seit ziemlich exakt 18:20 Uhr ist der Packet Loss verschwunden, das Routing vom Server nach UPC geht wieder über TATA, der Durchsatztest lag gerade bei ca. 4Mbit/s Server -> UPC - Das ist für "temporär" schon mal gut :-)
Beim Routing über TATA hatte sich vorher schon gezeigt, dass es zwar recht stabil ist, aber auch ziemlich Tageszeitabhängig... Wenn es geht, lasst es bitte erst mal so
Gruß, Klaus
ftp.ovh.net test.bin file
jetzt 200-230kbs
Zitat von
UPCUser
Edit: Es spricht doch nichts gegen eine temporäre Lösung bis Januar.. Hauptsache es läuft mal mit akzeptablem Speed.
Ja, an der arbeiten wir in diesem Moment... Kannst du jetzt nochmal testen (sowie erneuten traceroute posten falls nicht besser)
meine lösung sieht so aus
ich kündige den ovh server
ich wechsel den provider von upc/inode zu 99% a1telekom
und nehm mir dann wieder einen ovh server
nur das sollte keine lösung für keinen ovh/UPCInode-Kunden sein
das ist eine für österreichische zwitterlösung mit der ich nicht grad glücklich bin aber wenns klappt zufriedener
ich hoffe für ovh udn den anderne upc kunden das sich die problematik lösen lässt
Und wie sieht die entgültige Lösung aus ? Hat UPC zugesagt für den Traffic zu zahlen ? Oder werden die Routings geändert? Bis Jänner warten ist eine Katastrophe.
Eben getestet von einem PROOV.OVH bekomme ich mit nur einem Stream 200kbs und das bei meiner 100.000er Leitung....
Ping ist extrem schlecht und die 200kbs schwanken zwischen 10kbs!! und 200...
Schade ich hatte mich vor ein paar Wochen so gefreut da da ja alles bestens lief mit 12MB..
LG
Edit: Es spricht doch nichts gegen eine temporäre Lösung bis Januar.. Hauptsache es läuft mal mit akzeptablem Speed.
Hum, ok... Danke für das Feedback, ist schon weitergeleitet... Wir sind dran.
Eine endgültige (statt temporärer) Lösung ist in Sicht, kann aber voraussichtlich erst im Januar umgesetzt werden.
ich teste das mit filezilla auf
ftp.ovh.net
und lade das test.bin file
und habe 84kb/s (gerne auch screen wenn gewünscht)
traceroute zum ftp.ovh.net
Routenverfolgung zu ftp.ovh.net [213.186.33.9] über maximal 30 Abschnitte:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 57 ms 65 ms 48 ms 84.116.231.159
3 48 ms 47 ms 49 ms 84.116.229.185
4 48 ms 59 ms 48 ms at-vie-xion-pe02-vl-2054.upc.at [84.116.228.201]
5 47 ms 53 ms 59 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 51 ms 47 ms 49 ms 213.46.173.125
7 51 ms 61 ms 49 ms 213.46.176.118
8 53 ms 60 ms 60 ms prag-bb1-link.telia.net [213.155.133.66]
9 104 ms 183 ms 76 ms ffm-bb1-link.telia.net [213.155.130.202]
10 67 ms 66 ms 80 ms ffm-b10-link.telia.net [80.91.247.185]
11 * * * Zeitüberschreitung der Anforderung.
12 * * * Zeitüberschreitung der Anforderung.
13 * * * Zeitüberschreitung der Anforderung.
14 * * * Zeitüberschreitung der Anforderung.
15 * * * Zeitüberschreitung der Anforderung.
16 * * * Zeitüberschreitung der Anforderung.
tracerout kann ich von meinen noch im besitz befindlichen ovhserver machen
Routenverfolgung zu ks3094123.kimsufi.com [91.121.202.136] über maximal 30 Absch
nitte:
1 <1 ms <1 ms <1 ms fritz.box [192.168.178.1]
2 45 ms 46 ms 62 ms 84.116.231.159
3 58 ms 47 ms 47 ms 84.116.229.189
4 49 ms 48 ms 56 ms at-vie-xion-pe01-vl-2055.upc.at [84.116.229.9]
5 63 ms 61 ms 65 ms at-vie01a-rd1-vl-2050.aorta.net [84.116.228.193]
6 61 ms 47 ms 66 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.117
]
7 57 ms 51 ms 109 ms 213.46.176.118
8 88 ms 59 ms 61 ms win-bb2-link.telia.net [80.91.247.0]
9 72 ms 74 ms 78 ms ffm-bb2-link.telia.net [213.155.131.212]
10 64 ms 74 ms 57 ms ffm-b10-link.telia.net [80.91.247.189]
11 66 ms * * fra-5-6k.fr.eu [213.186.32.225]
12 73 ms 86 ms 81 ms rbx-g2-a9.fr.eu [91.121.131.130]
13 135 ms 82 ms 87 ms rbx-1-6k.fr.eu [91.121.131.13]
14 76 ms 75 ms 68 ms rbx-24-m1.fr.eu [213.251.191.67]
15 81 ms 84 ms 70 ms ks3094123.kimsufi.com [91.121.202.136]
als gegentest nehme ich speedtest.qsc.de
und habe 1.2mbit (auch hier screen möglich)
Routenverfolgung zu speedtest.qsc.de [195.90.7.115] über maximal 30 Abschnitte:
1 <1 ms 1 ms <1 ms fritz.box [192.168.178.1]
2 53 ms 47 ms 66 ms 84.116.231.159
3 60 ms 61 ms 63 ms 84.116.229.193
4 61 ms 48 ms 58 ms at-vie-xion-pe02-vl-2058.upc.at [84.116.228.209]
5 59 ms 64 ms 56 ms at-vie15a-rd1-vl-2051.aorta.net [84.116.229.1]
6 47 ms 84 ms 47 ms 213.46.173.125
7 62 ms 115 ms 50 ms 213.46.176.118
8 65 ms 67 ms 65 ms prag-bb1-link.telia.net [213.155.133.66]
9 65 ms 58 ms 64 ms ffm-bb1-link.telia.net [213.155.131.216]
10 70 ms 87 ms 83 ms ddf-b2-link.telia.net [213.155.135.93]
11 82 ms 83 ms 70 ms core1.dus.qsc.de [213.248.73.2]
12 86 ms 71 ms 70 ms core5.dus.qsc.de [213.148.134.110]
13 73 ms 84 ms 79 ms ssgate-ext.dus.qsc.de [87.234.8.210]
14 75 ms 74 ms 88 ms speedtest.qsc.de [195.90.7.115]
test proof.ovh
Last Result:
Download Speed: 2156 kbps (269.5 KB/sec transfer rate)
Upload Speed: 417 kbps (52.1 KB/sec transfer rate)
Latency: 506 ms
Montag, 19. November 2012 16:58:09
meine homeleitung ist
Empfangsrichtung Senderichtung
DSLAM-Datenrate Max. kbit/s 20000 1024
DSLAM-Datenrate Min. kbit/s 32 32
Leitungskapazität kbit/s 22820 859
Aktuelle Datenrate kbit/s 19994 826
besser?
130 kbit/s download von meinem ovh server.. das ist ein neuer mindestrekord ! Beim proof.ovh komm ich wenigstens auf 200kbit/s dafür ping 118ms und bei meinem server ping 33ms.
2 84.116.231.159 (84.116.231.159) 14.490 ms 7.776 ms 7.769 ms
3 84.116.229.193 (84.116.229.193) 20.139 ms 71.212 ms 10.067 ms
4 at-vie-xion-pe01-vl-2057.upc.at (84.116.229.13) 9.981 ms 9.021 ms 9.514 ms
5 at-vie01a-rd1-vl-2050.aorta.net (84.116.228.193) 9.160 ms 41.298 ms 9.188 ms
6 at-vie05b-ri2-xe-3-2-0.aorta.net (213.46.173.117) 8.837 ms 8.969 ms 7.813 ms
7 213.46.176.118 (213.46.176.118) 9.285 ms 11.764 ms 14.664 ms
8 win-bb2-link.telia.net (80.91.247.0) 14.539 ms 15.426 ms 14.963 ms
9 ffm-bb2-link.telia.net (213.155.133.54) 21.520 ms
ffm-bb2-link.telia.net (213.155.131.108) 21.356 ms
ffm-bb2-link.telia.net (213.155.133.54) 59.832 ms
10 ffm-b10-link.telia.net (80.91.251.124) 27.770 ms
ffm-b10-link.telia.net (80.91.251.250) 21.638 ms
ffm-b10-link.telia.net (80.91.247.189) 22.082 ms
11 fra-5-6k.fr.eu (213.186.32.225) 22.650 ms * *
12 rbx-g2-a9.fr.eu (178.33.100.250) 30.532 ms 30.536 ms 29.656 ms
13 * vss-2-6k.fr.eu (91.121.131.89) 29.916 ms 96.205 ms
14 serv8.foserv.fr (91.121.54.14) 29.195 ms 29.375 ms 29.876 ms
@edit: Okay bei proof.ovh schaffe ich inzwischen 5.35mbit/s. Das ist von meinen möglichen 20mbit/s noch weit entfernt aber schonmal ein anfang. Bei meinem server ist bei ~140kbit/s trotzdem schluss.
Ist es jetzt wieder besser?
Wenn nein, könnt ihr nochmal ein aktuelles traceroute posten?
Felix
Zitat von
FrankP
Hallo Darky68,
die Bearbeiterin, die sich um deinen Fall gekümmert hat, ist leider ein paar Tage ausgefallen. Die Übernahme Ihrer Fälle hat nicht richtig funktioniert - dafür entschuldige ich mich.
Ich hake gerne nochmal nach, wie der Stand der Dinge mit UPC ist. Versprechen kann ich da natürlich nichts - diese Probleme sind schon beim NOC bekannt.
Wer daran "Schuld" ist kann ich natürlich auch nicht sagen. ich gehe nicht davon aus, dass es an OVH liegt.
Geschwindigkeitsprobleme mit Anbieter Telekom sind mir momentan nicht bekannt.
Gruß
FrankP
OVH Team
Danke für die Anwort, das erklärt zumindest das supportproblem
schade ich werd mir evtl andern rootanbieter suchen müssen und
ICH HOFFE ES LIEST EIN UPC MITARBEITER - ich werde definitiv nächstes jahr UPC/INODE verlassen und zu telekom wechseln
ps ironienote am rande - man flüchtet von chello/upc vor 10jahren im jahr 2002 weils immer wieder probleme mit stabiler verbindung gab bzw geschwindigkeitsprobleme schon damals und wechselt zu inode einem privaten anbieter und ahtte aufeinmal VOLLE LEISTUNG
2006 kauft upc inode und was ist seit gut 3jahrne für probleme - die gleichen wie 2002 instablies internet geschwindigkeitseinbussen
auch ich gehe schon langsam davon aus und wenn das so ist, ist ovh schuldlos
das UPC hier massive eingriffe durchführt um wenig traffic zu haben oder von anderen firmen für traffic soviel kohle verlangen das die sich das nicht leisten können ..keine ahnung was stimmt - irgendwas davon wird stimmen
schade ovh wäre gern bei euch geblieben und hätte sogar noch stärken server gemietet - aber unter diesen umständen ist das rausgeschmissenes geld
@ OVH Team
Könntet ihr nicht mal den Link hierher einem zuständigen Mitarbeiter bei UPC senden? Wie man an den klicks sieht sind ja sehr viele Leute an dem Thread interessiert.
Mich würde interessieren warum wieder umgestellt wurde nachdem es ja schon funktioniert hat. Ein Normalsterblicher User kann bei UPC sicher nichts ausrichten, aber OVH ist ja kein normaler User.
Hier beschweren sich mittlerweile massiv Leute, aber es geschieht nichts.
Hallo Darky68,
die Bearbeiterin, die sich um deinen Fall gekümmert hat, ist leider ein paar Tage ausgefallen. Die Übernahme Ihrer Fälle hat nicht richtig funktioniert - dafür entschuldige ich mich.
Ich hake gerne nochmal nach, wie der Stand der Dinge mit UPC ist. Versprechen kann ich da natürlich nichts - diese Probleme sind schon beim NOC bekannt.
Wer daran "Schuld" ist kann ich natürlich auch nicht sagen. ich gehe nicht davon aus, dass es an OVH liegt.
Geschwindigkeitsprobleme mit Anbieter Telekom sind mir momentan nicht bekannt.
Gruß
FrankP
OVH Team
sehr geehrte damen und herren,
wie eben mit einem sehr netten freundlichen herren von ihnen gesprochen, teile ich ihnen mit das ich den gemieteten server nicht weiter mieten werde
dafür gibt es 2 sehr extrem unterschiedliche trifftige gründe
1. wenn ich mich mit ftp auf den server verbinde bekomme ich umd ie 200kb/s zusammen obwohl ich 1.9mbit schaffen könnte.
dies wurde auch mit ihrem ftp.ovh.net server getestet hier das gleiche problem . fazit liegt es entweder am routing von ovh zu mir oder an dem grund das ich bei dem provider inode (tochter von upc) bin und es hier probleme zw ovh und upc gibt.
gehe ich zb auf einen anderen test server speedtest.qsc.de erhalte ich sofort um die 1800-1900kb/s - also ist meine homeleitung vollkommen für mich inordnung udn das problem tritt nur mit servern der firma OVH auf. auch dies wurde getestet mit freunden aus deutschland die bei ihnen einen server haben und auch dort habe ich die gleichen geschwindigkeitsprobleme
fazit liegt der grund für mich als laie an ovh und oder upc
2. das hinhalten des support ist eine frechheit. ein ticket mit dem problem am 3.11 eröffnet bis 9.11 mit blablabla hingehalten alles getestet was gefordert , dann verlangt in rescue mode zugehen udn auf die frage meiner seits an welchen tag(weil kann ja ned ewig den server in rescue lassen) bekam ich vom 9.11 bis heute 19.11 - 10 TAGE LANG KEINE ANTWORT !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
mfg
sr58367-ovh
PS mich würd schon interessieren wer jetzt wo die schuld trägt upc/inode oder ovh mit dem routing nach österreich zu dne upc/inode kunden
ka bin laie
jetzt stellt sich noch eine frage für mich - wenn ich provider wechsel zb zu telekom hab ich da die gleichen probleme?????
Natürlich betrifft das mich aus, weil ich unzählige User in ganz Europa mit meinem Server darüber bediene. Das ist nicht gerade wenig, bei einige PB Gesamtvolumen pro Jahr. Nur was bringt das Jammern, dass was gesagt werden musste wurde alles gesagt. Weiteres Jammern bringt es nicht weiter, eine Statistik hin oder her.
Wer wirkliches Interesse daran hat, wendet sich an
oles@ovh.net. Für wen die Anbindung geschäftskritisch ist, muss eben die Konsequenzen ziehen und wechseln bzw. Alternativen für diese User anbieten.
Zitat von
UPCUser
Die Frage ist doch --> zuerst ging es nicht, dann hat es für ca. 1 Woche hingehauen mit Downloadgeschwindigkeiten bis 12 MB/s und jetzt geht es wieder nicht...
TATA Traffic ist einfach zu teuer für UPC. Wenn die Provider sich querstellen, soll es nicht ander´s sein. Wenn UPC ein Angebot geben täte, dass normal auf dem Markt ist würde OVH sicher nicht nein sagen. Aber für solchen Traffic solche Preis zu verlangen und doppelt zu kassieren geht nicht.
Die Frage ist doch --> zuerst ging es nicht, dann hat es für ca. 1 Woche hingehauen mit Downloadgeschwindigkeiten bis 12 MB/s und jetzt geht es wieder nicht... Also ist denen das Problem durchaus bekannt... Nur eine Stellungnahme bleibt aus :/ Dann sollen sie gleich sagen "Wir wollen nicht" ... UPC und OVH ist dieser Thread sicher bekannt....
Da komme ich ja gerade richtig. Wie ich sehe, wird der Ton schon schärfer hier.
Ich sehe auch, dass das Thema wohl nicht gerade uninteressant ist, denn es wurde innerhalb kurzer Zeit bereits fast 5000 Mal gelesen.
Die aktuellen Werte sind derzeit ca. 1 Mbit/s von OVH nach UPC (eben noch testen lassen), Routen stehen massenhaft zur Verfügung, der definierte Zeitpunkt, wann das wieder so drastisch schlecht wurde ist, als das Routing von TATA wieder auf upc.as6830.at.eu geroutet wurde.
Dazu kommt - wie ich auch bereits schon schrieb - eine gehörige Portion Packet Loss.
Es wurde bereits von Felix (OVH) gesagt, dass dran gearbeitet wird, es wäre dann jetzt auch mal an der Zeit, mal einen Zwischenstand zu erfahren, ich denke, das ist bei den Werten wirklich angebracht.
Gruß, Klaus
Zitat von
strex
...
Wie gesagt, dass Jammer bringt nichts. Hatten wir mit der Telekom hier in .de auch in den 2010. Das hat dann rund ein Jahr gedauert und die Uplinks wurden dann trotzdem bezahlt. Der Kundenmarkt ist für OVH wohl zu klein, um viel zu überteuerte UPC Leitungen zu buchen.
Eine Rechtfertigung, "früher war die Anbindung woanders schlecht" ist ein Witz. Wenn Dich das "Gejammere" stört, dann behalte es doch einfach für Dich, es geht darum ein Problem, welches Dich scheinbar nicht betrifft, aufzuzeigen. Mit meinem Beitrag wollte ich auf objektive Weise mit aktuellen Marktanteilen die Bedeutung dieses Providers verdeutlichen.
Du hast keinerlei Garantien auf bestimmte Bandbreite zu bestimmten Zielen. Dir wird ja nicht mal vollständig die Bandbreite des Servers garantiert.
Wenn du was garantiert haben möchtest, dann musst du entsprechend mehr ausgeben. Gibt das dein Projekt nicht her, sollte es eigengestellt werden.
Wie gesagt, dass Jammer bringt nichts. Hatten wir mit der Telekom hier in .de auch in den 2010. Das hat dann rund ein Jahr gedauert und die Uplinks wurden dann trotzdem bezahlt. Der Kundenmarkt ist für OVH wohl zu klein, um viel zu überteuerte UPC Leitungen zu buchen.
Kann leider das Problem nur bestätigen. Es ist echt frustrierend, ich wählte einen Server-Provider mit begrenztem Inklusiv-Traffic und klar definierter Server-Anbindung. Und dann wird doch wieder irgendwo gedrosselt.
Warum ist mir eigentlich egal. CH ist ein relevanter Markt für meine Einnahmen und letztendlich Finanzierung der Server und UPC/Cablecom macht als grösster Kabelanbieter knapp 30% dieses Marktes aus (
http://www.comcom.admin.ch/dokumenta...x.html?lang=de).
Drosselung bei Excessive use ist ok, aber nicht für eine bezahlte Dienstleistung und da sehe ich ovh in der Pflicht, sei es in Form von mehr Investitionen in die Peering Anbindung oder in Form des bitteren Apfels Transit.
wird es hierfür noch einmal ein update geben oder wars das mit ovh als upc kunde ?
Super ! sehe gerade 0 % Auslastung auf der Weathermap, demnach dürfte die Geschwindigkeit noch über der 100mbit marke liegen
Leider halt nur im Traum, die Geschw. ist nach wie vor lahm.
Im Vergleich dazu hat OVH mit LiWest keine Probleme, 1.000 kb mit 1er Verbindung, da können UPC Kunden (derzeit) nur davon träumen.
wenn manche schreiben das sie gerade mit ein paar hundert kb/s sich herumschlagen müssen, dacht ich mir ich bring das mit meiner 16er mal an...
Danke für die Steinigung...
Kein teurer Telia Traffic an UPC Kunden, richtig so! Mit der Telekom ham sie sich ja auch geeinigt, wenn UPC nicht will, dann nicht
Ich habe UPC 100 Mbit und erreiche Rund um die Uhr damit MINDESTENS 90 MBIT.... Ich denke nicht das man das mit ner 16.000er von A1 vergleichen kann, von dem mal abgesehen wenn du nur 400 Meter vom Wählamt wech bist dann drosseln sie dich schon auf ne 8000er weil ja mehr angeblich nicht geht.... Ich habe nen Root und will den auch mit anständigem Speed nutzen können, und warum sollte ich wechseln?? Vor ein zwei Wochen ging es doch, nur wurde mal wieder was umgestellt....
Zitat von
tester
ich hab dort gigaspeed 16 und komm auch auf die 16mbit zu jeder Tageszeit
Aber das ist ja viel viel weniger als die 50MBit Ich will doch mehr als meine Kollegen haben (auch wenn ich den Speed eh nicht immer krieg) aber auf die Zahl/Größe die da steht kommts doch an, oder?
wie wärs eigentlich wenn ihr zu nem anderen inet anbieter wechselts ? a1 z.b. ?
ich hab dort gigaspeed 16 und komm auch auf die 16mbit zu jeder Tageszeit
da bin ich ja mit meinen 3mbit/s download welche ich erreiche ja noch richtig schnell dran im vergleich zu andere !
Zitat von
strex
... Seiten wie youtube oder google lahm werden, dann geht´s fix. Das ist aber noch nicht erreicht, wird aber kommen.
Das war schon:
http://futurezone.at/digitallife/101...it-youtube.php
Zitat von
Katzi
..
Wenn bei 70-80% aller Österreichischen / Schweitzer Kunden das "lahm" bleibt muss man sich eben von OVH trennen und den Server woanders mieten.
...
Mit dieser Lösung unterstützt du nur die UPC mit ihrem Verhalten. Ist wie bei der DTAG, die wollen einfach doppelt kassieren. Deshalb irgendwann wir der Punkt erreicht sein, wo die Provider nicht mehr zahlen wollen und Seiten wie youtube oder google lahm werden, dann geht´s fix. Das ist aber noch nicht erreicht, wird aber kommen.
Ob sich die Kosten für die paar Kunden die von UPC angebunden sind rentiert, ich weiß es nicht, scheinbar ist das OVH zu teuer und es muss sich dann also nicht rentieren. Dann ändert sich auch nichts. Dann solltest du ein Wechsel in Betracht ziehen, weil das wäre für beide Partner die beste Lösung.
Zitat von
strex
Der Telia Traffic ist einfach zu teuer um den an UPC zu verschenken. Wenn die kein Upgrade wollen oder nur gegen Geld, bleibt´s halt lahm für UPC Kunden..
Das Problem an der sache ist.,d as die UPC in Österreich quasi Monopolöstellung hat.
Was wiederum bedeutet das man kaum eine Wahl hat welchen ISP man sich nimmt.
Wenn bei 70-80% aller Österreichischen / Schweitzer Kunden das "lahm" bleibt muss man sich eben von OVH trennen und den Server woanders mieten.
Es ist ja eine Zumutung bei einer 100mbit leitung nur 75 kb/s zu bekommen.
Wäre mal nicht schlecht wenn sich jemand von den OVH Mitarbeitern zu dem Thema äußern würde.
Der Telia Traffic ist einfach zu teuer um den an UPC zu verschenken. Wenn die kein Upgrade wollen oder nur gegen Geld, bleibt´s halt lahm für UPC Kunden..
Also wenn man sich das mal anguckt und die Posts zurückverfolgt, ab wann die Probleme aufhörten und wieder anfingen, kann man hier eindeutig darauf schließen, dass da irgendwo rumgefummelt wurde
http://p19.smokeping.ovh.net/ovh-ser...1348956000.png
Hi,
auch noch ein paar Infos:
vom Server (Roubaix 1):
Code:
Host Loss% Snt Last Avg Best Wrst StDev
1. rbx-6-m1.fr.eu 0.0% 214 0.4 0.6 0.4 5.4 0.4
2. rbx-1-6k.fr.eu 8.4% 214 61.3 8.2 0.2 235.0 33.0
3. rbx-g2-a9.fr.eu 0.0% 214 0.8 11.9 0.6 293.0 48.9
4. fra-5-6k.fr.eu 29.6% 213 8.2 18.0 7.9 301.8 32.4
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
fra-5-6k.fr.eu
5. pra-1-6k.cz.eu 7.5% 213 16.1 25.6 15.9 217.6 32.8
6. vie-1-6k.at.eu 3.8% 213 20.6 26.5 20.5 244.9 29.2
7. upc.as6830.at.eu 6.1% 213 42.8 27.3 26.3 72.0 4.5
8. at-vie01a-rd1-xe-1-0-0.aorta.net 4.7% 213 21.9 27.9 21.4 86.7 11.1
9. at-vie-sk11-pe01-vl-2042.upc.at 4.7% 213 26.8 27.7 26.6 68.2 4.8
10. at-vie-sk11-pe02-vl-1.upc.at 5.2% 213 21.6 24.0 21.4 58.5 7.5
11. ???
12. chelloxxxxxxxxxxxx.20.11.vie.surfer.at 6.1% 213 43.3 34.2 27.9 93.9 8.5
Wobei ich mich echt wundere, was für ein IP-Adressen-Wunder der fra-5-6k ist :-)
Vom UPC Kunden (Wien):
Code:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 23 | 23 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 4 | 0 | 0 | 0 | 0 | 0 |
| 84.116.4.49 - 0 | 23 | 23 | 7 | 14 | 41 | 10 |
| at-vie15a-rd1-vl-2043.aorta.net - 0 | 23 | 23 | 8 | 15 | 40 | 15 |
| 213.46.173.125 - 0 | 23 | 23 | 8 | 17 | 42 | 33 |
| 213.46.176.118 - 0 | 23 | 23 | 8 | 14 | 51 | 8 |
| win-bb2-link.telia.net - 0 | 23 | 23 | 13 | 20 | 38 | 17 |
| ffm-bb2-link.telia.net - 0 | 23 | 23 | 24 | 29 | 46 | 26 |
| ffm-b10-link.telia.net - 0 | 23 | 23 | 22 | 30 | 61 | 27 |
| fra-5-6k.fr.eu - 28 | 11 | 8 | 0 | 40 | 69 | 26 |
| rbx-g2-a9.fr.eu - 6 | 19 | 18 | 29 | 37 | 51 | 32 |
| rbx-2-6k.fr.eu - 14 | 15 | 13 | 30 | 34 | 51 | 33 |
| rbx-6-m1.fr.eu - 6 | 18 | 17 | 28 | 34 | 49 | 34 |
| xxxxxxx.tv - 6 | 19 | 18 | 28 | 34 | 52 | 32 |
|________________________________________________|______|______|______|______|______|______|
OVH Speedtest von dort:
http://s1.directupload.net/images/121105/crlv35gr.jpg
Der Packet Loss ist tatsächlich in beide Richtungen verdächtig identisch.
Zumindest lässt sich sehr genau sagen, wann der Loss angefangen hat, denn nach den Anfängen mit langsamen Verbindungen läuft auf einer meiner nicht ausgelasteten Kisten in Roubaix 1 Smokeping, der folgendes zeigt:
http://s7.directupload.net/images/121105/orxnktbl.png
Das deckt sich dann wohl mit den Aussagen, dass es so ca. zwischen dem 31.10. und 1.11. irgendwie langsamer geworden ist ....
Das sind mit den anderen zusammen aber jetzt reichlich Infos
Gruß, Klaus
Eigentlich sieht man doch klar wo das Problem liegt.
Der Traffic geht jetzt wieder von OVH übers direkte Peering mit UPC in Wien, und das ist einfach überlastet. Das war schon der Fall, dann ging zeitweise alles nen anderen Weg (über telia glaube ich) wo es funktioniert hat, und jetzt läufts wieder über das private Peering mit UPC.
Normalerweise bin ich kein Mensch der sich öffentlich leicht aufregt, aber ich verstehe nicht warum man da jetzt überhautp noch traceroutes braucht, wenn das Problem sogar schon für mich ersichtlich ist?! Ihr solltet das doch als erstes sehen oder wissen wenn irgendwas an eurem Routing geändert wurde?!
Sorry wenn ich mich jetzt hier aufrege, aber ich bin davon ausgegangen dass das Problem mit UPC vom Tisch ist ....
Hier aus Wien, über UPC:
Von UPC zu OVH:
Code:
3 9 ms 9 ms 8 ms 84.116.6.129
4 11 ms 27 ms 9 ms at-vie01a-rd1-vl-2018.aorta.net [84.116.228.29]
5 10 ms 9 ms 10 ms at-vie05b-ri2-xe-3-2-0.aorta.net [213.46.173.11
6 30 ms 20 ms 10 ms 213.46.176.118
7 36 ms 15 ms 15 ms win-bb2-link.telia.net [213.155.133.76]
8 63 ms 57 ms 22 ms ffm-bb2-link.telia.net [213.155.133.54]
9 36 ms 44 ms 25 ms ffm-b10-link.telia.net [213.155.134.137]
10 * 21 ms * fra-5-6k.fr.eu [213.186.32.225]
11 31 ms 30 ms 50 ms rbx-g2-a9.fr.eu [91.121.131.130]
12 87 ms 66 ms 31 ms rbx-s2-6k.fr.eu [178.33.100.94]
Von OVH zu UPC:
Code:
traceroute to 84.116.6.129 (84.116.6.129), 30 hops max, 60 byte packets
1 * * *
2 rbx-g2-a9.fr.eu (178.33.100.89) 0.787 ms 2.311 ms 2.315 ms
3 fra-5-6k.fr.eu (178.33.100.245) 8.132 ms fra-5-6k.fr.eu (178.33.100.251) 8.095 ms *
4 * * *
5 * * *
6 upc.as6830.at.eu (91.121.131.66) 26.473 ms 26.549 ms 26.516 ms
7 at-vie01a-ra3-ge-0-1-0.aorta.net (213.46.173.118) 46.574 ms 41.006 ms 27.504 ms
8 84.116.228.30 (84.116.228.30) 42.010 ms * *
Speedtest proof.ovh.net:
http://www0.xup.in/exec/ximg.php?fid=21143004
Speedtest.net zu einem Server in Linz:
http://www.speedtest.net/result/2288087494.png
Hallo,
hier mal ein Ergebnis wie es zu mir in die Schweiz aussieht:
http://i.imm.io/KymC.jpeg
Traceroute zum Server:
Code:
Routenverfolgung zu ks3262608.kimsufi.com [5.39.77.139] über maximal 30 Abschnitte:
1 8 ms 7 ms 8 ms 84-74-12-1.dclient.hispeed.ch [84.74.12.1]
2 9 ms 8 ms 7 ms 217-168-55-173.static.cablecom.ch [217.168.55.173]
3 9 ms 10 ms 12 ms 62.2.4.177
4 * * 10 ms nl-ams05a-rd2-xe-4-1-1.aorta.net [84.116.134.22]
5 10 ms 11 ms 12 ms 213.46.171.66
6 21 ms 25 ms 22 ms ffm-bb1-link.telia.net [213.155.133.214]
7 22 ms 20 ms 20 ms ffm-b10-link.telia.net [80.91.247.185]
8 64 ms 45 ms * fra-5-6k.fr.eu [213.186.32.225]
9 45 ms 30 ms 35 ms rbx-g2-a9.fr.eu [91.121.131.134]
10 36 ms * 29 ms vss-9b-6k.fr.eu [178.33.100.74]
11 29 ms 27 ms 29 ms ks3262608.kimsufi.com [5.39.77.139]
Ablaufverfolgung beendet.
Und vom Server zu mir:
Code:
traceroute to 84-74-12-28.dclient.hispeed.ch (84.74.12.28), 30 hops max, 60 byte packets
1 * * *
2 rbx-g2-a9.fr.eu (91.121.131.157) 2.354 ms 2.346 ms 2.326 ms
3 fra-5-6k.fr.eu (178.33.100.251) 8.041 ms * *
4 zur-1-6k.ch.eu (94.23.122.146) 15.299 ms * *
5 upc.as6830.ch.eu (94.23.122.166) 17.349 ms 17.334 ms 17.312 ms
6 ch-zrh02a-ra1-xe-3-2-0.aorta.net (84.116.134.21) 17.676 ms 17.852 ms 17.817 ms
7 62.2.4.178 (62.2.4.178) 17.794 ms 62.2.4.182 (62.2.4.182) 18.088 ms 62.2.4.178 (62.2.4.178) 17.941 ms
8 * * *
9 * * *
Früher ging es über Level(3) mit Fullspeed...
[EDIT]: Zum Vergleich, dass ich meine Leitung ausschliessen kann:
http://www.speedtest.net/result/2287958373.png
Zitat von
UPCUser
Wieso sollte ich den Root Anbieter wechseln...
Wenn dir die Gegebenheiten nicht passen, ist ein Umzug die beste Wahl. Da dein Fordern nichts bringt bleibt dir nichts anders übrig, vielleicht wollen ja beide oder einer von beiden nicht die Kapazität erhöhen. Eine Garantie das es super laufen muss gewährt dir aus guten Gründen keiner, also hast du kein Anrecht. Dann kannst du so viel Fordern wie du willst, bringen tut es nichts. Es hilft hier dann nur noch ein Wechsel. Klar? Sollte doch nicht schwer sein.
Zitat von
UPCUser
Was heisst zum Zeitpunkt wenn das Problem auftritt, das Problem besteht die ganze Zeit... Schau dir mal die Weathermap an.. sagt eh schon alles.
Dir ist aber schon bekannt, dass sich das Routing öfters verändern kann und das Frames nicht denselben Hin- und Rückweg nehmen können. Da die Uplinkkapazität nicht von heute auf morgen zunimmt und dann Tage wieder später abnimmt, hat sich etwas am Routing geändert.
Wenn du eventuell eine Behebung willst, dann poste die geforderten Daten oder lebe mit dem Speed.
Was heisst zum Zeitpunkt wenn das Problem auftritt, das Problem besteht die ganze Zeit... Schau dir mal die Weathermap an.. sagt eh schon alles.
zakazak wrote:
> Und das wars dann wieder.
>
> Seit gestern sind nicht mehr wie 2 mbit/s drinnen...
Die übliche Rückfrage - Könnt ihr zum Zeitpunkt wenn das Problem auftritt
traceroutes machen und diese posten? Idealerweise in beide Richtungen, also
einmal UPC => OVH und einmal OVH => UPC.
Wieso sollte ich den Root Anbieter wechseln ? Nur weil UPC oder OVH das nicht gebacken bekommt?? Das ist doch nicht mein Problem... und das es funktionieren kann hat man ja gesehen, da es ja vor ein Paar Tagen noch funktioniert hat... Nur haben die ja anscheinend wieder was umgestellt... und das obwohl alles ging..
BITTE OVH setzt euch doch mal mit UPC in Verbindung...
selbst um 4 Uhr am Morgen ist die Auslastung noch immer kanpp bei 50 %
O.k. Speed ist besser dann , aber je später der Tag wird, desto höher wird die Auslastung.
Zur Zeit (8:12) ist sie schon bei 63%.
Ab 12 Uhr Mittag ist dann sowieso schluss , dann geht nichts mehr (90%).
Noch vor 6 Tagen war Abends so gegen 18:00 die Auslastung sogar noch unter 30 %
UPC vertickt halt immer gerne fette leitungen, investiert aber nicht gerne in den Netzausbau.
Es ist hier wohl UPC Austria gemeint, nach UPC Schweiz funktioniert auch alles
Hetzner und Hosteurope sind nach UPC Österreich übrigens schnell mit mehreren MB/sec. Ohne da jetzt irgendwie Schleichwerbung machen zu wollen, nur falls hier jemand Kunden aus Österreich hat die sich schon wieder anfangen zu beschweren ...
Wenn euch der Speed zu UPC wichtig ist, warum wählt ihr dann keinen Provider direkt in der Schweiz? Vielleicht einmal ein Server in SBG 1 testen, dort läuft der Traffic direkt von Straßburg nach Frankfurt und Zurich an UPC. Die Links sind nicht ausgelastet.
Ich würde jetz gern mal wissen wer da jetzt wirklich Schuld ist, UPC schiebts auf OVH und umgekehrt.... Kann ja nicht angehn das ich mit ner 100mbit Leitung nicht meinen Server nutzen kannn hier.... OVH sollte sich mal mit UPC in verbindung setzen.... so gehts nicht!!
Kann ich bestätigen.
Speed ist für UPC Kunden leider wirklich wieder grottig ... Jetzt kann ich die Server bei anderen Hostern wohl doch nicht durch OVH Server ersetzen ...
Stimmt, ist mir auch schon aufgefallen und die Weathermap zeigt bis zu 90% Auslastung.... Wär auch zu schön gewesen.... Das kanns doch echt nicht mehr sein!!
Und das wars dann wieder.
Seit gestern sind nicht mehr wie 2 mbit/s drinnen...
Hmm naja ist doch egal, die Hauptsache ist doch das es flutscht. Und wo lag dann der Fehler?
MFG
Zitat von
UPCUser
Hab ich ja auch nicht behauptet, habe ja auch gesagt das die Routings gleich geblieben sind. Nur wie gesagt seit mehr Channels zur Verfügung stehen läuft es... Mir egal warum, Hauptsache es läuft und die basteln nicht wieder rum.
Die Channels in deinem Modem beeinfluss aber bei weitem nicht die Peering Kapazität zwischen den beiden. Das ist Bestens ein Zufall mehr nicht.
Das Routing von dir zu OVH wurde nicht geändert. Die andere Richtung allerdings, also von OVH zu dir, wurde geändert
Hab ich ja auch nicht behauptet, habe ja auch gesagt das die Routings gleich geblieben sind. Nur wie gesagt seit mehr Channels zur Verfügung stehen läuft es... Mir egal warum, Hauptsache es läuft und die basteln nicht wieder rum.
Modem Downstream Channels oder ähnliches hat aber nichts mit dem Routing zwischen OVH und UPC zu tun. Daran liegt es nicht.
So hab mich jetzt hier extra mal registriert.
Bin auch UPC Kunde aus Wien und nach langer Zeit geht endlich mal der Download von OVH Servern flott. Erreiche bis zu 100 Mbit. Wenn man sich die Weathermap ansieht aus Wien sieht man das es die gleichen Routings sind aber die Kapazität anscheinend erhöht wurde.
Was mir aufgefallen ist, ist das in den Modem die Downstream Channels von 4 auf 8 erhöht wurden. Daduch sind meine Leitungswerte etwas schlechter geworden (vor allem beim letzten Channel) aber dafür flutscht jetzt auch der Download von OVH...
Ich hoffe mal das das so bleibt und UPC nicht wieder etwas umstellt, also der Fehler lag eindeutig bei UPC wenns jetzt mit den extra Channels besser flutscht.
Wow!
Gerade mal von UPC Wien aus testen lassen. Download einzelner TCP Stream: Bis zu 40 MBit/s, mit mehreren parallel geht's bis 100MBit (mein testender UPC Kunde hat nicht mehr downstream).
Die Routen sind übrigens geblieben. Irgendeiner hat wohl an irgendeiner Stelle die Kapazität erhöht :-)
Code:
|------------------------------------------------------------------------------------------|
| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
|------------------------------------------------|------|------|------|------|------|------|
| 192.168.1.1 - 0 | 7 | 7 | 0 | 0 | 0 | 0 |
| No response from host - 100 | 1 | 0 | 0 | 0 | 0 | 0 |
| 84.116.4.49 - 0 | 7 | 7 | 6 | 18 | 51 | 51 |
| at-vie15a-rd1-vl-2043.aorta.net - 0 | 7 | 7 | 11 | 17 | 38 | 11 |
| 213.46.173.129 - 0 | 7 | 7 | 10 | 17 | 33 | 33 |
| 213.46.176.118 - 0 | 7 | 7 | 10 | 13 | 18 | 12 |
| win-bb2-link.telia.net - 0 | 7 | 7 | 16 | 20 | 28 | 28 |
| ffm-bb2-link.telia.net - 0 | 7 | 7 | 23 | 43 | 125 | 23 |
| ffm-b10-link.telia.net - 0 | 7 | 7 | 24 | 26 | 29 | 28 |
| fra-5-6k.de.eu - 25 | 4 | 3 | 0 | 81 | 187 | 28 |
| rbx-g2-a9.fr.eu - 0 | 7 | 7 | 35 | 40 | 50 | 42 |
| rbx-2-6k.fr.eu - 25 | 4 | 3 | 0 | 33 | 37 | 32 |
| rbx-6-m1.fr.eu - 0 | 7 | 7 | 32 | 49 | 137 | 34 |
| xxxxxxx.tv - 25 | 4 | 3 | 0 | 35 | 38 | 33 |
|________________________________________________|______|______|______|______|______|______|
Gruß, Klaus
Edit sagt: Der 25% Packet Loss ist ein Winmtr Bug Es geht auch ohne.
eben mal nen ösi testen lassen, 6mb/s von nem Superplan ... kann man lassen.
welten besser als die 500k/s sonst.
Es läuft momentan über Tata und das wirklich wie geschmiert, hoffen wir, dass es so bleibt
Sehr schön, es funktioniert zur Zeit wirklich schön schnell!
Sehe ich das richtig, dass ihr jetzt garnicht mehr euer privates Peering mit UPC benutzt? Ganz schön frech, aber scheint eine sehr gute Entscheidung gewesen zu sein!
kann ich bestätigen ! sehr nice
ping ist nun auch von ~38ms runter auf 30ms.
Ein Wunder ist geschehen?
http://i.imm.io/Gwl8.png
Ist völlig egal, wer hier Schuld hat. Wenn sich alle auch bei UPC beschweren und nicht nur bei OVH, ist die Chance so oder so größer dass da mal irgendwas passiert.
@Hook: Warum sollen wir uns bei upc beschweren?
Das Problem liegt auf OVH Seite, ich habe andere Server die gehen über die gleichen Transit Links und haben keine Speedprobleme.
Einfach ist OVH zu geizig den "Premiumtraffic" von UPC zu zahlen...
Denn ich kann hier kein UPC Problem erkennen:
Code:
Routenverfolgung zu bene.us [176.31.109.151] über maximal 30 Abschnitte:
1 6 ms 6 ms 6 ms 84-74-12-1.dclient.hispeed.ch [84.74.12.1]
2 8 ms 9 ms 9 ms 217-168-55-173.static.cablecom.ch [217.168.55.173]
3 10 ms 14 ms 14 ms 62.2.4.177
4 17 ms 11 ms 11 ms ch-zrh02a-ra1-xe-5-1-0.aorta.net [84.116.134.58]
5 * 10 ms 9 ms ch-zrh01b-ra1-ae-1.aorta.net [84.116.134.142]
6 12 ms 10 ms 10 ms 4.68.127.49
7 40 ms 11 ms 12 ms ae-11-11.car2.Zurich1.Level3.net [4.69.133.234]
8 16 ms 15 ms 15 ms ae-7-7.ebr2.Frankfurt1.Level3.net [4.69.133.237]
9 18 ms 24 ms 22 ms ae-92-92.csw4.Frankfurt1.Level3.net [4.69.140.30]
10 * * 16 ms ae-4-90.edge5.Frankfurt1.Level3.net [4.69.154.201]
11 18 ms * 16 ms fra-5-6k.de.eu [91.121.131.5]
12 57 ms 53 ms * rbx-g2-a9.fr.eu [91.121.131.134]
13 321 ms * 109 ms vss-6a-6k.fr.eu [91.121.128.40]
14 162 ms 101 ms 162 ms srv.rollik.net [176.31.109.151]
Ablaufverfolgung beendet.
Sondern es schaut einfach nur so aus, als das OVH das Routing zu UPC nicht vernünftig gebacken bekommt...
Bitte einfach mal alle bei UPC direkt beschweren, die davon betroffen sind. Und auch andere Leute animieren sich an die zu wenden.
Was anderes hilft in dem Fall glaub ich einfach nicht.
350kbit/s.. mehr gehen nicht. Zu keiner tageszeit..
Das hört sich gut an. Teilweise gehen anscheinend über (jetzt etwas andere) Telia Links zwischen Roubaix und Wien manchmal sogar bis zu 10 MBit/s :-)
Gut, dass ihr dran bleibt.
Gruß, Klaus
zakazak wrote:
> Hey ich konnte heute schon 3 mbit/s erreichen.
>
> Das ganze ist irgendwie lächerlich. Vorallem wenn ich meinen server
> bloß für mich private nutze.
Wir sind mit UPC in Kontakt, und es ist auch Besserung in Aussicht... Wird
allerdings noch einige Wochen brauchen.
peering bei upc in at
oder
network bei upc in at
mal probiert?
(Insbesondere wenn man dort Kunde ist)
Zitat von
Hook
Beschwert euch bitte alle mal bei eurem Provider wenn ihr davon betroffen seid.
Ich hab die schon nen paar mal kontaktiert, bin da allerdings nicht Kunde und entsprechend wenig wird man vermutlich auch ernst genommen.
Aus meiner Erfahrung wirst du von dem Support eh nicht ernstgenommen/die können im Prinzip auch nichts tun außer es weiterzuleiten...
Beschwert euch bitte alle mal bei eurem Provider wenn ihr davon betroffen seid.
Ich hab die schon nen paar mal kontaktiert, bin da allerdings nicht Kunde und entsprechend wenig wird man vermutlich auch ernst genommen.
Oder einfach mal kündigen, dann rufen die sowieso nochmal an, fragen nach dem Grund und versprechen einem das blaue vom Himmel wenn man die Kündigung zurückzieht. Oder ist das in Österreich anders?
Ich würd als OVH ja einfach hingehen und den ganzen Traffic einfach übers VIX routen, falls möglich und auf UPC sche**en .... So viel höher dürfte die Latenz dann auch nicht sein, oder?
Hey ich konnte heute schon 3 mbit/s erreichen.
Das ganze ist irgendwie lächerlich. Vorallem wenn ich meinen server bloß für mich private nutze.
Anscheinend nicht, ausser die Häufung von Fragen von UPC Usern, wieso unser Server so schlecht zu erreichen ist.
Bei ca. 2 MBit/s download (vom Server zum UPC Kunden) und zeitweise bis 6% Packet Loss ist das jetzt nicht gerade befriedigend :-(
Gruß, Klaus
Anscheinend gibts immernoch keine Neuigkeiten?
Ich glaube, so einfach ist das nicht Ich habe im Moment auch das Gefühl, dass das Problem tatsächlich bei UPC liegt, ich habe gottseidank sehr guten Kontakt zu einem UPC Kunden (daher ist auch das tracert), wir haben auch mal von drei.at (UMTS) getraced, das Routing geht ganz brav über VIX und steigt in Wien ins OVH Netz ein.
Dazu müsste aber vielleicht noch mal jemand von OVH was sagen, wenn kar ist, was da überhaupt passiert
Im Moment ist der Durchsatz von UPC Kunden denkbar schlecht. Ich frage mich auch, wie die beiden UPC Links so ausgelastet sind, wenn wir es von UPC aus nicht schaffen, über diesen vorgesehenen Weg zu gehen :-)
Gruß, Klaus
Zitat von
Caddy
Zwischen UPC und OVH läuft aber generell derzeit etwas schief:
[ ... ]
Ich denke, UPC sollte doch eigentlich direkt auch von client zum OVH Netz über euer Peering direkt in Wien gehen, oder sehe ich das falsch?
Diese Informationen haben sowohl OVH als auch UPC von mir bereits mehrmals bekommen. Bisher ist aus User-Sicht allerdings rein garnichts passiert.
Ich denke die österreichischen UPC Kunden sollten einfach mal ihren Provider nerven, irgendwann müssen die ihr Peering mit OVH ja mal upgraden. OVH hat ja soweit ich das sehe eine sehr gute Peering-Policy. Allerdings habe ich das Gefühl, dass Störungsmeldungen oder Beschwerden bei UPC in Ablage P verschwinden ... Auf Emails wird nicht reagiert und ein Anruf bringt nur die Antwort "wir werdens weiterleiten" ...
Könnte man nicht als Load-Balancing zu UPC-Kunden noch einfach das VIX-Peering hinzuschalten? Da ist laut der weathermap zumindest noch genug Luft.
Zwischen UPC und OVH läuft aber generell derzeit etwas schief:
traceroute von einem UPC user zu unserem OVH Server:
Code:
Routenverfolgung zu x [87.98.216.x] über maximal 30 Abschnitte:
1 * * * Zeitüberschreitung der Anforderung.
2 * * * Zeitüberschreitung der Anforderung.
3 18 ms 17 ms 13 ms 84.116.4.33
4 12 ms 16 ms 19 ms at-vie15a-rd1-vl-2043.aorta.net [84.116.228.129]
5 20 ms 9 ms 12 ms 213.46.173.125
6 22 ms 14 ms 19 ms 213.46.176.118
7 23 ms 25 ms 18 ms win-bb2-link.telia.net [213.155.133.78]
8 31 ms 31 ms 28 ms ffm-bb2-link.telia.net [80.91.246.142]
9 83 ms 41 ms 37 ms prs-bb2-link.telia.net [213.155.132.154]
10 39 ms 42 ms 87 ms prs-b4-link.telia.net [80.91.251.114]
11 * 34 ms * gsw-1-6k.fr.eu [213.251.130.81]
12 42 ms 39 ms 41 ms th2-g1-a9.fr.eu [91.121.215.134]
13 37 ms 37 ms 34 ms rbx-g1-a9.fr.eu [91.121.215.133]
14 44 ms * 77 ms rbx-2-6k.fr.eu [213.186.32.234]
15 43 ms 42 ms 38 ms rbx-6-m1.fr.eu [213.251.191.141]
16 41 ms 36 ms 36 ms x [87.98.216.x]
Ablaufverfolgung beendet.
Von unserem OVH Server aus zu eben demselben User:
Code:
traceroute to x (213.47.115.x), 30 hops max, 60 byte packets
1 rbx-6-m1.fr.eu (87.98.216.253) 0.591 ms 0.757 ms 0.973 ms
2 rbx-2-6k.fr.eu (213.251.191.130) 204.752 ms * *
3 rbx-g2-a9.fr.eu (91.121.131.10) 2.459 ms 2.474 ms 2.479 ms
4 fra-5-6k.fr.eu (178.33.100.245) 23.180 ms fra-5-6k.fr.eu (178.33.100.255) 23.113 ms *
5 pra-1-6k.cz.eu (213.251.128.109) 16.089 ms * *
6 vie-1-6k.at.eu (213.251.128.98) 20.593 ms * *
7 upc.as6830.at.eu (94.23.122.98) 29.519 ms 29.455 ms 29.434 ms
8 at-vie01a-ra3-ge-0-1-0.aorta.net (213.46.173.118) 36.795 ms 25.357 ms 24.407 ms
9 at-vie-sk11-pe01-vl-2042.upc.at (84.116.228.126) 30.230 ms 30.226 ms 30.084 ms
10 at-vie-sk11-pe02-vl-1.upc.at (212.17.99.138) 30.347 ms 30.373 ms 30.143 ms
11 chello213047115xxx.20.11.vie.surfer.at (213.47.115.x) 35.805 ms 34.803 ms 39.595 ms
Ich denke, UPC sollte doch eigentlich direkt auch von client zum OVH Netz über euer Peering direkt in Wien gehen, oder sehe ich das falsch?
Besagter User bekommt derzeit von allen unseren OVH Servern ca. 2 Mbit/s pro TCP stream. Öffnet er 2 Downloads, bekommt jeder ca. 2Mbit/s ...
Gruß, Klaus
Das dachte ich mir schon.
Danke trotzdem.
Hook wrote:
> Gibts denn schon Neuigkeiten?
Nein, die Kommunikation scheint etwas zaeh zu sein...
Gibts denn schon Neuigkeiten?
Habt ihr auch mal drüber nachgedacht, das ganze private Peering mit UPC einfach sein zu lassen und alles übers decix oder was weiß ich laufen zu lassen? Offensichtlich ist der Provider ja nicht in der Lage, sein Netzwerk ordentlich zu pflegen ...
Hier mal nen traceroute von nem hetzner Server auf ne IP die von dem Problem betroffen ist. Mit hetzner gibts wie oben beschrieben keine Probleme.
Code:
traceroute to 80.108.240.125 (80.108.240.125), 30 hops max, 60 byte packets
1 static.x.x.x.176.clients.your-server.de (176.x.x.x) 0.038 ms 0.010 ms 0.008 ms
2 hos-tr4.juniper2.rz14.hetzner.de (213.239.224.225) 0.132 ms hos-tr3.juniper2.rz14.hetzner.de (213.239.224.193) 0.126 ms 213-239-224-129.clients.your-server.de (213.239.224.129) 0.135 ms
3 hos-bb1.juniper4.ffm.hetzner.de (213.239.240.230) 4.835 ms 4.818 ms 4.794 ms
4 tengigabitethernet9-4.ar3.fra3.gblx.net (207.138.95.9) 19.537 ms 19.570 ms 19.683 ms
5 po2-20G.ar4.FRA3.gblx.net (67.16.133.34) 19.532 ms 19.580 ms 19.630 ms
6 de-fra01a-ri2-xe-0-3-0.aorta.net (213.46.179.65) 5.020 ms 69.838 ms 69.812 ms
7 de-fra01a-rd3-xe-1-0-0.aorta.net (213.46.179.98) 18.956 ms de-fra01a-rd3-xe-0-0-0.aorta.net (213.46.179.109) 18.925 ms de-fra01a-rd3-xe-1-0-0.aorta.net (213.46.179.98) 18.919 ms
8 at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.160.134) 17.344 ms 84.116.136.105 (84.116.136.105) 17.497 ms at-vie15a-rd1-xe-4-3-0.aorta.net (213.46.160.134) 17.462 ms
9 84.116.228.34 (84.116.228.34) 18.544 ms 17.620 ms 17.508 ms
10 * * *
11 chello080108240125.2.14.vie.surfer.at (80.108.240.125) 50.862 ms 50.854 ms 34.641 ms
Hook wrote:
> Ich stelle schon seit mehreren Wochen fest, dass das Routing vor allem
> nach UPC ziemlich schlecht ist. Es werden abends oft nicht mal 100kb/sec
Zwischenstand: Das NOC steht mit UPC in Kontakt um eine Lösung zu finden.
kann ich bestätigen, mit einer Verbindung 150-250 kb/s
Von hetzner 4mb/s zu jeder Tageszeit
bin atm bei der telekom, erreiche mit einer verbindung 650kb/s
das is mein leitungsmaximum
Ich stelle schon seit mehreren Wochen fest, dass das Routing vor allem nach UPC ziemlich schlecht ist. Es werden abends oft nicht mal 100kb/sec erreicht, Mittags und Nachts sind zwar höhere Geschwindigkeiten möglich, allerdings auch selten mehr als 1MB/sec.
Auch von einem Kunden der Telekom Austria habe ich bereits Beschwerden über eine langsame Verbindung bekommen.
Wenn man auf der Weathermap nachsieht, sind die Peerings auch fast zu jeder Tageszeit über 70%. Viel höher gehts einfach nicht, nur die Datenraten sinken in den Abendstunden ab. Ich denke also nicht dass es an OVH direkt liegt, sondern an UPC.
Direkte Nachfragen bei UPC haben bisher auch nichts gebracht, angeblich wird das entsprechend weitergeleitet. Aber vermutlich ging das in die Ablage P ....
Kann OVH eventuell mal bei UPC Druck machen, damit das Peering verbessert wird?
Zum Vergleich sind von hetzner, hosteurope oder von fdcservers (zlin) etwa 4MB/sec (maximum) pro Verbindung möglich, lediglich OVH wird "gedrosselt" und ist für die entsprechenden Nutzer schon fast eine Zumutung ....
