xDSL.at

Morgen,

ich war in den letzten Jahren Kunde bei Tele2 (ADSL 16/1), aber da mir deren "Servicepauschale" aus Prinzip gegen den Strich geht und ich früher schon einmal bei Silver Server war - sehr zufrieden, nur damals im Vergleich zu teuer -, dachte ich, ich könnte doch einfach wieder zurück wechseln. Und siehe da, Sil hatte ADSL 16/1 ums selbe Geld. Geesagt, getan: Seit ein paar Tagen habe ich Tele2 auf Leitung 1 und Sil auf Leitung 2. Eigentlich hatte ich nicht damit gerechnet, daß es Unterschiede geben würde, aaaber:

Die Bandbreite (up und down) ist bei Silver Server um ~15% schlechter und, und das ist der Knackpunkt, die Latenz bei weitem. Dabei scheint die ADSL-Leitung an sich nicht schuld zu sein: Der Ping auf den jeweils ersten Hop dahinter ist bei Sil nur 2,5 ms schlechter (Durchschnitt von 100 Pings), das wäre völlig wurscht. Leider ist es in der Praxis schlimmer.

Speedtest.net (Wien/Drei): Tele2 6-8 ms, Sil 32-42 ms
Google.at: Tele2 17-19 ms, Sil 30-35 ms
Lieblings-TF2-Server (modme.info, via ICMP und UDP getestet): Tele2 20-23 ms, Sil 40-50 ms

Ich hab in den letzten Tagen wirklich so Einiges getestet und für die meisten kontinentaleuropäischen Destinationen kann man fast 20 ms auf die Tele2-Werte aufschlagen. Na, denk ich mir, merkt eh keiner. Aber der Rest der Familie beschwert sich schon und ehrlich gesagt merk ich's auch. Vielleicht die höhere Latenz, vielleicht deren Schwankung.

Dem Sil-Support ist das uncharakteristischerweise herzlich egal: "Wir garantieren keine Latenzen."

Hatte ich mit Tele2 nur extrem viel Glück oder ist Silver Server tatsächlich dabei, abzubauen? Sparen sie etwa in letzter Zeit bei den (internationalen) Anbindungen? Oder gibt's jetzt für Privatkunden QoS 2. Klasse? Ich weiß nicht, ich bin aus allen Wolken gefallen.

Mal sehen, vielleicht komme ich aus dem Vertrag noch raus, aber mit meiner bisher uneingeschränkten Silver Server Empfehlung war's das für's Erste.

Ich behaupte mal, du bekommst nicht mal QoS 5. Klasse... Nämlich eher gar keins...

Im Gegenteil zu dir wird sogar recht gewettert, wenn der Provider in den Traffic seiner Kunden eingreift...

wicked_one hat geschrieben:Ich behaupte mal, du bekommst nicht mal QoS 5. Klasse... Nämlich eher gar keins...
Im Gegenteil zu dir wird sogar recht gewettert, wenn der Provider in den Traffic seiner Kunden eingreift...

Ehrlich gesagt verstehe ich deinen Post nicht ganz.
Technisch wäre es durchaus möglich, verschiedene Kundenklassen über verschiedene Routen laufen zu lassen oder sie innerhalb einer Route vor- bzw. nachzureihen. Es wäre halt eine Erklärung dafür, daß die Silver Server Leistung diesmal so schlecht ist.

Technisch geht viel... Such mal den Thread über UPC und deren Traffic shaping bei torrents... Du wirst verstehen.

wicked_one hat geschrieben:Technisch geht viel... Such mal den Thread über UPC und deren Traffic shaping bei torrents... Du wirst verstehen.

Jaja, ist bekannt. Hat aber immer noch nichts mit dem Thema zu tun.

1.) Doch viel, die schriebst, du denkst an benachteiligung durch QoS, ich dementierte...
2.) QoS welcher Art erhöht die Latzenz nicht nachhaltig. würde wirklich ein solches wirken, würdes du es allenfalls temporär merken.

Somit ist IMO QoS vom Tisch.

Gut 10 ms würde ich mal darin vermuten, dass T2 fast immer Fastpath verwendet, wovon viele andere Provider mittlerweile absehen.

Das andere würd ich mal darin sehen, dass SIL einfach andere Routingwege nimmt, als T2 - und andere seit deinem letzten Kundendasein bei SIL. DIe Latenzzeiten sind voll im akzeptablen Rahmen, und somit würde ich dir auch nicht mehr sagen als der Support von SIL: "Wir garantieren keine Latenzen." - wobei ich eh schon mehr gesagt habe, als diese...

wicked_one hat geschrieben:QoS welcher Art erhöht die Latzenz nicht nachhaltig. würde wirklich ein solches wirken, würdes du es allenfalls temporär merken.

Jemminee, wir reden immer noch von unterschiedlichen Dingen. QoS kann mehr sein, als nur Beschränkung der Banbreite nach irgendwelchen Kriterien.
Angenommen es gibt zwei Routen zum Ziel, eine direkte mit wenigen Hops und schnellen Routern, die den ISP auf irgendeine Weise teurer kommt, und einen "Umweg", der nichts kostet - natürlich wirkt sich das auf die Latenz aus, wenn man auf die zweite Art geroutet wird. Keine Ahnung, ob's tatsächlich so gemacht wird, ich suche nur nach einer Erklärung.

Gut 10 ms würde ich mal darin vermuten, dass T2 fast immer Fastpath verwendet, wovon viele andere Provider mittlerweile absehen.

Das würde sich doch nur auf die Stecke Modem--DSLAM auswirken, oder? Die ist noch recht ok.

Das andere würd ich mal darin sehen, dass SIL einfach andere Routingwege nimmt, als T2 - und andere seit deinem letzten Kundendasein bei SIL. DIe Latenzzeiten sind voll im akzeptablen Rahmen [...]

Das wird's schon sein. Aber wenn die Routen durchgehend länger und schlechter wurden, muß man eben sagen, Silver Server hat in den letzten Jahren abgebaut. Im, Rahmen, ja ... im vertraglich zumutbaren, wahrscheinlich; im für mich akzeptablen, nein; im Rahmen dessen, was man von einem Premium-ISP erwartet, sicher nicht.

im Rahmen dessen, was man von einem Premium-ISP erwartet, sicher nicht.

Dann bleibt wohl nur der Weg zum Salzamt...

Ein Traceroute würde glaub ich helfen um zu sehen wo genau es hapert

Stefan Hedenig hat geschrieben:Ein Traceroute würde glaub ich helfen um zu sehen wo genau es hapert :)

Gute Idee, aber schlau werd ich nicht draus:

Runde 1: modme.info
UDP-Traceroute, weil im Standard-Modus die letzten paar Hops nur timeouten.

Code: Alles auswählen

# Tele 2
$ traceroute -M udp modme.info
traceroute to modme.info (188.40.66.181), 30 hops max, 60 byte packets
1  crabtree.southpark.chp (192.168.0.1)  0.162 ms  0.191 ms  0.287 ms
2  192.168.1.1 (192.168.1.1)  1.126 ms  1.170 ms  1.611 ms
3  [externe IP zensiert]  12.835 ms  12.874 ms  15.614 ms
4  195.248.59.65 (195.248.59.65)  12.360 ms  13.698 ms  15.488 ms
5  eh56wger01-vl803.net.uta.at (195.248.61.101)  16.529 ms  17.967 ms  19.102 ms
6  eh56wmich01-vl802.net.uta.at (195.248.61.97)  83.592 ms  82.321 ms  82.076 ms
7  eh56wmich02-vl825.net.uta.at (195.248.61.226)  21.563 ms  23.058 ms  24.299 ms
8  c76wmich2-vl810.net.uta.at (195.248.61.130)  33.611 ms  23.132 ms  22.519 ms
9  c76wintx1-ten3-3.net.uta.at (212.152.192.106)  17.105 ms  17.835 ms  17.290 ms
10  wen3-core-1.tengigabiteth11-0.tele2.net (130.244.49.117)  18.275 ms  18.884 ms  18.972 ms
11  wien-s2-rou-1041.at.eurorings.net (193.203.0.97)  48.335 ms  44.349 ms  42.851 ms
12  wien-s2-rou-1002.AT.eurorings.net (134.222.123.245)  29.628 ms  26.873 ms  26.874 ms
13  mchn-s1-rou-1022.DE.eurorings.net (134.222.228.45)  27.373 ms  27.075 ms  27.122 ms
14  mchn-s1-rou-1021.DE.eurorings.net (134.222.229.89)  28.576 ms  29.529 ms  30.574 ms
15  nbg-s1-rou-1001.DE.eurorings.net (134.222.225.30)  30.775 ms  20.082 ms  20.333 ms
16  kpn-gw.hetzner.de (134.222.107.21)  20.336 ms  20.034 ms  20.432 ms
17  hos-bb2.juniper1.fs.hetzner.de (213.239.240.146)  22.835 ms  22.581 ms hos-bb2.juniper2.fs.hetzner.de (213.239.240.147)  32.465 ms
18  hos-tr3.ex3k4.rz10.hetzner.de (213.239.227.197)  24.380 ms hos-tr2.ex3k4.rz10.hetzner.de (213.239.227.165)  23.277 ms  24.673 ms
19  modme.info (188.40.66.181)  25.812 ms  26.741 ms  22.626 ms

# Silver Server
$ traceroute -M udp modme.info
traceroute to modme.info (188.40.66.181), 30 hops max, 60 byte packets
1  crabtree.southpark.chp (192.168.0.1)  0.215 ms  0.249 ms  0.342 ms
2  [externe IP zensiert]  1.182 ms  1.182 ms  1.217 ms
3  vie-91-186-158-000.dsl.sil.at (91.186.158.0)  14.588 ms  15.429 ms  16.614 ms
4  Ge2-19-decix-c1.ix.sil.at (80.81.192.85)  19.806 ms  19.803 ms  20.341 ms
5  decix2-gw.hetzner.de (80.81.193.164)  39.751 ms  39.793 ms  39.836 ms
6  hos-bb1.juniper2.fs.hetzner.de (213.239.240.243)  60.793 ms hos-bb1.juniper1.fs.hetzner.de (213.239.240.242)  44.579 ms  33.801 ms
7  hos-tr4.ex3k4.rz10.hetzner.de (213.239.227.229)  36.490 ms hos-tr1.ex3k4.rz10.hetzner.de (213.239.227.133)  39.476 ms hos-tr4.ex3k4.rz10.hetzner.de (213.239.227.229)  39.567 ms
8  modme.info (188.40.66.181)  39.511 ms  34.550 ms  36.191 ms


Die Sil Route ist nicht einmal halb so lang, ohne die Hops innerhalb der beiden Provider-Netze ist es fast eine Direktverbindung - trotzdem ~12 ms mehr. (TF2 selbst zeigt übrigens ~25 ms für T2 und ~50 ms für Sil an.)


Runde 2: www.google.at

Code: Alles auswählen

# Tele 2
$ traceroute -M icmp www.google.at
traceroute to www.google.at (74.125.39.147), 30 hops max, 60 byte packets
1  crabtree.southpark.chp (192.168.0.1)  0.232 ms  0.278 ms  0.323 ms
2  192.168.1.1 (192.168.1.1)  1.070 ms  1.267 ms  1.515 ms
3  [externe IP zensiert]  12.446 ms  14.540 ms  15.438 ms
4  195.248.59.65 (195.248.59.65)  12.541 ms  13.884 ms  15.381 ms
5  eh56wger01-vl803.net.uta.at (195.248.61.101)  16.623 ms  18.123 ms  19.320 ms
6  eh56wmich01-vl802.net.uta.at (195.248.61.97)  22.062 ms  20.719 ms  21.852 ms
7  eh56wmich02-vl825.net.uta.at (195.248.61.226)  26.234 ms  25.824 ms  25.816 ms
8  c76wmich2-vl810.net.uta.at (195.248.61.130)  25.551 ms  15.488 ms  16.628 ms
9  c76wintx1-ten3-3.net.uta.at (212.152.192.106)  17.006 ms  18.049 ms  18.455 ms
10  wen3-core-1.tengigabiteth11-0.tele2.net (130.244.49.117)  19.224 ms  19.335 ms  19.146 ms
11  wen1-core-1.pos0-0.tele2.net (130.244.205.49)  19.392 ms  17.589 ms  18.824 ms
12  fra50-core-1.pos0-12-0-0.tele2.net (130.244.205.41)  36.365 ms  32.233 ms  31.771 ms
13  fra36-core-2.tengigabiteth3-4.tele2.net (130.244.52.173)  31.456 ms  32.668 ms  33.605 ms
14  peer-as15169.fra36.tele2.net (130.244.200.118)  33.722 ms  33.114 ms  33.226 ms
15  209.85.241.144 (209.85.241.144)  33.420 ms  33.162 ms  33.271 ms
16  209.85.254.114 (209.85.254.114)  34.072 ms 209.85.254.116 (209.85.254.116)  33.160 ms  33.470 ms
17  209.85.254.126 (209.85.254.126)  43.857 ms 209.85.249.162 (209.85.249.162)  19.449 ms  25.272 ms
18  fx-in-f147.1e100.net (74.125.39.147)  21.415 ms  19.629 ms  21.064 ms

# Silver Server
$ traceroute -M icmp www.google.at
traceroute to www.google.at (209.85.148.106), 30 hops max, 60 byte packets
1  crabtree.southpark.chp (192.168.0.1)  0.229 ms  0.271 ms  0.370 ms
2  [externe IP zensiert]  1.064 ms  1.112 ms  1.113 ms
3  vie-91-186-158-000.dsl.sil.at (91.186.158.0)  14.436 ms  14.885 ms  16.080 ms
4  Ge2-19-decix-c1.ix.sil.at (80.81.192.85)  17.874 ms  18.821 ms  19.768 ms
5  de-cix20.net.google.com (80.81.193.108)  37.387 ms  38.832 ms  39.729 ms
6  209.85.255.176 (209.85.255.176)  48.862 ms  47.674 ms  47.909 ms
7  209.85.254.41 (209.85.254.41)  44.855 ms  44.501 ms 209.85.254.57 (209.85.254.57)  45.836 ms
8  fra07s07-in-f106.1e100.net (209.85.148.106)  46.276 ms  42.945 ms  43.549 ms


Selbes Bild hier ... 8 vs 18 Hops und trotzdem ~24 ms schlechtere Latenz.

Was hier so steht scheint auf ein Kapazitätsproblem von SIL am DECIX hinzuweisen - ist aber nur eine Vermutung.

4 Ge2-19-decix-c1.ix.sil.at (80.81.192.85) 19.806 ms 19.803 ms 20.341 ms
5 decix2-gw.hetzner.de (80.81.193.164) 39.751 ms 39.793 ms 39.836 ms

und

4 Ge2-19-decix-c1.ix.sil.at (80.81.192.85) 17.874 ms 18.821 ms 19.768 ms
5 de-cix20.net.google.com (80.81.193.108) 37.387 ms 38.832 ms 39.729 ms

sind jeweils Hops, die sich am DE-CIX befinden - und da solltest du niemals 20ms dazwischen haben, außer der DECIX Port (in diesem Fall scheinbar am Router 80.81.192.85) ist überfüllt.

Ich denke das sollte ein temporäres Problem sein, bis am DECIX der Port passend aufgestockt (zb. auf Port-Channel) wurde. Halt vielleicht so 1-3 Wochen durch

Danke, das ist die erste sinnvolle Antwort zu dem Thema.

Schade nur, daß sowas nicht von Silver Server selbst kommt. Über ein "Ja schauen's, viele Ihrer Testfälle rennen über XY, dort gibt's gerade einen Engpaß, wir arbeiten dran." hätte ich nichts gesagt, im Gegenteil - ich schätze Transparenz. Aber ein (freundlicher formuliertes aber inhaltlich identisches) "Es gibt kein Problem, und bis zum Ende der MVD müssen's jetzt so und so damit leben." hätte ich eher anderswo erwartet.

Ich glaub sobald man Privatkunden hat, rufen manchmal die unmöglichsten Leute mit den noch viel unmöglicheren Sichtweise und Anliegen an.

Insofern kann ich schon verstehen, dass einem Kunden nicht immer der rote Teppich ausgerollt wird.

So ... nach ca. einer Million Abwimmel-e-Mails -- ich fühle mich an den Chello-Helpdesk von anno dazumal erinnert -- endlich eine Erklärung: Angeblich befindet sich der eine Hop in Wien, der andere in Frankfurt und für die Distanz sei das normal. Mir kommt's immer noch zuviel vor, für ~750 km Luftlinie, aber gut.

Das eigentliche Problem ist damit natürlich immer noch weder gelöst noch erklärt.

Highlights vom Support: "Ich hoffe, Ihnen ist bewusst, dass die Performance einer Leitung nicht
an den Antwortzeiten zu messen ist." und "Ich habe Antwortzeiten von 50ms und erhalte trotzdem die
volle Bandbreite."

Schade, war einmal - auch für Privatkunden - ein echt guter Provider.

Ich hoffe einfach mal dass dir da jemand geantwortet hat der sich nicht auskennt...

Ripe Auszug:
inetnum: 80.81.192.0 - 80.81.195.255
netname: DE-CIX-FRA-IXP
descr: DE-CIX Frankfurt IXP

Der Hop, der sich angeblich noch in Österreich befinden soll, ist IP-mäßig definitiv dem DE-CIX in Frankfurt zugewiesen.
Und dass SIL so wahnsinnig ist, die DE-CIX Peerings zwischen Wien und Frankfurt hin und her zu schleifen (das kostet saumäßig viel Geld), anstatt den Traffic direkt in Frankfurt zu lassen, würde jeglicher sinnhaftigkeit und wirtschaftlichkeit entbehren...

Ich bleib dabei - sitz es ein paar wochen aus, vermutlich wird im Core eh schon daran gearbeitet den DE-CIX Port aufzufetten.