Latenz-Probleme mit Silver Server

[wicked_one]

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

Right, solche Sachen haben sich immer noch von alleine gelöst, und bis dahin werden Kunden mit allerlei erklärungen abgespeisst, ... aber auch 100 Mails bewirken hier kaum beschleunigung.

[ANOther]

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."

2x die volle wahrheit gesprochen.
naja, vermutlich. ich weiss nicht, ob der sprecher WIRKLICH die volle bandbreite (wieviel von wovon) erhält (aber wenn man davon ausgeht hatta recht...)

[local.host]

die DE-CIX Peerings zwischen Wien und Frankfurt hin und her zu schleifen

remote peering?
gut, das würde die Sache nicht wirklich erklären.

(das kostet saumäßig viel Geld),

VIE-FRA? nimmer wirklich.

anstatt den Traffic direkt in Frankfurt zu lassen, würde jeglicher sinnhaftigkeit und wirtschaftlichkeit entbehren...

ACK

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

da bin ich bei dir.

[fallenguru]

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

Ja, da kannst schon einmal Gift drauf nehmen. Dummerweise weigert sich der Herr auch standhaft, das Ganze an jemanden weiterzugeben, der sich auskennt. Ich selber hab zwar einen Informatik-Background, aber von Netzwerktechnik auf dem Niveau auch nicht den blassesten Schimmer

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

Right, solche Sachen haben sich immer noch von alleine gelöst, und bis dahin werden Kunden mit allerlei erklärungen abgespeisst, ... aber auch 100 Mails bewirken hier kaum beschleunigung.

Wahrscheinlich, aber ich laß mich ehrlich gesagt nur sehr ungern verarschen und der Kontakt mit dem Kundendienst war bis jetzt unter jeder Kritik. Ich finde eine ehrliche, technisch korrekte Auskunft nicht zuviel verlangt - is ja früher auch gegangen.

[wicked_one]

Also reden wir gar nicht mehr über das Problem, sondern die Haltung deines providers dazu...

[_Riddik_]

hy,

Wahrscheinlich, aber ich laß mich ehrlich gesagt nur sehr ungern verarschen und der Kontakt mit dem Kundendienst war bis jetzt unter jeder Kritik. Ich finde eine ehrliche, technisch korrekte Auskunft nicht zuviel verlangt - is ja früher auch gegangen.

Ehrlich gesagt versteh ich den Support. Denn selbst die 20ms fallen unter die Wahrnehmungsgrenze.
Wobei auch Pings selber vl. nicht priorsiert werden und dadurch höher ausfallen und daher
auch keine wirkliche Referenz.

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.

Was ist daran falsch ? Ich bezweifle das selbst Hardcore Gamer Pingzeiten Unterschiede unter 50 ms noch
wahrnehmen - geschweige denn User bei normalen Anwendungen.
Somit ist es auch irrelevant ob nur 20ms oder 40ms dafür verwendet werden, abgesehen mal davon
das vl. Ping Pakete nicht priorisiert werden.

Würde ich persönlich dort sitzen hätte ich demjenigen schon mal nen Rechenschieber statt einen
Pc aufgedrückt - weil das sind Peanuts

Lg

[wicked_one]

Genial.

Ich glaub das ist die Losung, QoS mit LLQ und Bandbreitenreservierung für ICMP und Speedest Traffic.

Dass das restliche Internet dann langsam ist, ist egal, Hauptsache die traces und speedtests schauen gut aus...

[reallumpi]

DIr ist schon klar das beim DE-CIX (afaik) alle IP's auf die Colo in Frankfurt geriped sind oder ? Ich hätte auf die schnelle keine DE-CIX IP gefunden die auf das InterXion in Wien läuft, dort ist aber definitiv der DE-CIX Knoten den die .at ISP's verwenden

[fallenguru]

Also reden wir gar nicht mehr über das Problem, sondern die Haltung deines providers dazu...

Naja, ich dachte, wir sind uns einig, daß ich nichts gegen das Problem unternehmen kann, und es ist offensichtlich, daß Silver Server, wenn überhaupt, von selbst etwas dagegen tut. Wenn euch noch etwas zur technischen Seite einfällt, bin ich natürlich ganz Ohr.

Ehrlich gesagt versteh ich den Support. Denn selbst die 20ms fallen unter die Wahrnehmungsgrenze.

Selbst wenn dem so wäre - wenn vergleichbare Zugänge ~20 ms für die ganze Strecke brauchen, sind 20 ms zusätzlich schon happig. (Das sind Daumen-mal-Pi-Werte für Westeuropa. Sicher, auf Interkontinentalstrecken is sowieso alles egal.)
Natürlich kann man damit leben, aber State of the Art ist das nicht - und wenn sich nie wer beschwert gibt's bald auch auf verkabelten Zugängen Latenzen wie bei HSPA ... brr.

Wobei auch Pings selber vl. nicht priorsiert werden und dadurch höher ausfallen und daher
auch keine wirkliche Referenz.

Ich glaub das ist die Losung, QoS mit LLQ und Bandbreitenreservierung für ICMP und Speedest Traffic.

Das hab ich mit dem Support auch schon durchgekaut. Es gibt keine Unterschiede zwischen ping (ICMP), traceroute (div. UDP-Varianten, div. TCP-Varianten und ICMP) und den auf Applikationsebene gemessenen Anwortzeiten. Wenn überhaupt, sind letztere noch etwas schlechter. Das ist kein Benchmark-Artefakt.

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."

Was ist daran falsch ?

1) Wieso sollte die Latenz einer Internet-Anbindung (Höhe und Schwankungen) plötzlich kein gültiges Maß für die Qualität eines Internet-Zugangs mehr sein? Wenn man sich jetzt einmal auf ADSL-Zugänge beschränkt, ist die Bandbreite ohnehin überall gleich und damit zweitrangig. Da bietet sich die Latenz als (vom Kunden) messbares Vergleichkriterium an. Zuverlässigkeit, technische Ausstattung, peerings, Kundenservice, ... sind halt sehr schwierig zu ermitteln und/oder objektiv zu bewerten.
Wäre mir alles bis auf die Bandbreite egal, wäre ich bei Chello oder einem HSPA-Provider.

2) Der Satz ergibt keinen Sinn.
Bandbreite und Latenz sind, für unsere Zwecke, unabhängig. (Je fetter die Leitung, desto geringer die minimal mögliche Latenz, ja, aber das wird, was "meine" Bandbreite betrifft, nur zwischen Modem und DSLAM schlagend und da paßts ja. Dahinter ist alles 1+ Gbit/s, das fällt nicht mehr ins Gewicht. Impliziert wird ein umgekehrter Zusammenhang also Latenz -> Bandbreite. Kann man auch konstruieren, z. B. auf einer Strecke mit hohem BDP (sehr hohe Bandbreite, ewig lange Leitung) und nicht dafür konfigurierten Endpunkten, wird die effektive Bandbreite massiv einbrechen. Trifft hier wohl auch nicht zu. )

Ich bezweifle das selbst Hardcore Gamer Pingzeiten Unterschiede unter 50 ms noch
wahrnehmen - geschweige denn User bei normalen Anwendungen.
Somit ist es auch irrelevant ob nur 20ms oder 40ms dafür verwendet werden, [...]

Das klingt für mich irgendwie nach "Wozu ein Auto, das über 160 km/h schafft, wo man doch selbst auf der Autobahn nur 130 fahren darf."

Spaß beiseite, sowas summiert sich. Selbst bei einer komplexen Web Site (viele kleine Dateien) geht das recht bald Richtung Sekunden-Bereich.

[jutta]

hat mit dem problem hier nur am rande zu tun, aber da der fehler immer wieder gemacht wird, erwaehne ich es:

Runde 2: http://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
<snip>

# Silver Server
$ traceroute -M icmp www.google.at
traceroute to www.google.at (209.85.148.106), 30 hops max, 60 byte packets
<snip>


schon die erste zeile der traceroutes zeigt, dass http://www.google.at (und auch jede andere google adresse) fuer latenz vergleiche nicht geeignet ist. dank globalem load-balancing weiss man naemlich nie, in welchem teil der welt die pings landen werden. auch kurz hintereinander durchgefuehrte ping oder traceroute muessen nicht zum selben host fuehren, wie die ip adressen schoen zeigen. daher sind auch die strecken dorthin weder vorhersehbar noch reproduzierbar.

[jutta]

> Das klingt für mich irgendwie nach "Wozu ein Auto, das über 160 km/h schafft, wo man doch selbst auf der Autobahn nur 130 fahren darf."

und was ist daran falsch? schnellere autos sind gut fuer schwanzvergleiche, "schnellerer" ping ebenfalls.

> sowas summiert sich. Selbst bei einer komplexen Web Site (viele kleine Dateien) geht das recht bald Richtung Sekunden-Bereich.

erklaer das bitte genauer.

zum zusammenhang ping, bandbreite, performanz:

wir sind uns einig, dass die bandbreite eh passt und dass bandbreite und latenz je nach konstellation zusammenhaengen koennen, aber nicht muessen.

aber: die latenz (das was du mit ping oder traceroute misst) hat auch wenig damit zu tun, wie rasch datenpakete von da nach dort transportiert werden, denn hochleistungsrouter und switches sind dafuer konfiguriert, dass sie pakete schupfen und nicht dafuer, dass sie im traceroutevergleich gut aussehen. (das steht uebrigens schon x-mal hier im forum, auch von berufeneren backbone-netzwerkspezialisten als von mir geschrieben). die datenpakete koennen auch noch pfeilschnell flutschen, wenn ein router bei ping rtts von 200ms und mehr produziert.

im uebrigen: der einzige provider, der eine zusage ueber die latenz gemacht hat, war die selige eunet. und auch die hat das nur fuer das eigene netz gemacht und nicht fuer internationale datenverbindungen.

wenn du auf eine bestimmte maximal-latenz auf internationalen strecken wert legst, landest du bei ganz anderen produkten als adsl/vdsl zu ganz anderen preisen.

[fallenguru]

da der fehler immer wieder gemacht wird [...] load-balancing [...]

Danke, ist bekannt. Zu Diagnosezwecken ist sowas wirklich nur bedingt geeignet, zu Bewertungszwecken aber m. E. schon. Soo schnell wird man (von derselben IP) nicht plötzlich ans andere Ende der Welt umgeleitet und welchen von x unter- / nebeneinander stehenden Hosts im selben Data Center man bekommt, sollte ziemlich egal sein.
Beim direkten Vergleich zwischen zwei Providern zum selben Zeitpunkt geht es ja auch nicht darum, die Qualität der Verbindung zu einer bestimmten IP zu ermitteln, sondern die zu einem bestimmen Dienst. Daß der dann je nach Provider eventuell von verschiedenen IPs an verschiedenen physischen Orten zur Verfügung gestellt wird, ist für den Kunden ja nicht relevant.

Mittelfristig kann man so und so nichts vergleichen, schließlich können sich die Routen (auch qualitativ) zwischen x-beliebigen zwei IPs auch jederzeit verändern.

sowas summiert sich. Selbst bei einer komplexen Web Site (viele kleine Dateien) geht das recht bald Richtung Sekunden-Bereich.

erklaer das bitte genauer.

Jede Datei (die HTML-Seite selber, Bilder, Skripte, ...) braucht, wenn die Verbindung nicht gerade mit Pipelining gesegnet ist, eine eigene TCP-Verbindung und da müssen ein paar Pakete synchron hin und her, bevor die steht ("handshake"). Die Latenz, die zwischen dir und dem Web Server besteht, kommt also mehrmals pro Datei zum Tragen. Dadurch, daß die meisten Browser heutzutage mehrere Verbindungen parallel aufbauen, hält sich das im Rahmen, aber unmerklich ist es nicht.

wir sind uns einig, dass die bandbreite eh passt und dass bandbreite und latenz je nach konstellation zusammenhaengen koennen, aber nicht muessen.

Ja. Allerdings bin ich der Meinung, daß es eben in dieser Konstellation keinen relevanten Zusammenhang gibt.

aber: die latenz (das was du mit ping oder traceroute misst) hat auch wenig damit zu tun, wie rasch datenpakete von da nach dort transportiert werden, denn hochleistungsrouter und switches sind dafuer konfiguriert, dass sie pakete schupfen und nicht dafuer, dass sie im traceroutevergleich gut aussehen.

"Rasch" kann Verschiedenes bedeuten. Extrembeispiele: Wenn es darum geht, große Datenmengen von A nach B zu verschieben, dann geht es am schnellsten, wenn man ein paar 2TB Platten in ein Paket steckt und per Express verschickt. Viel schneller als via Internet, aber die Latenz liegt im Bereich von Tagen. Wenn man automatisiert und in Echtzeit an den Finanzmärkten aktiv sein will, sieht die Sache schon ganz anders aus - so eine Order ist nicht groß, aber es kommt auf jede Millisekunde an.

Ob ping und traceroute die Latenz korrekt messen, ist eine ganz andere Frage, wahrscheinlich nicht. Aber bessere Instrumente haben wir nicht und die Latenz ist eben auch in der Praxis zu hoch.

im uebrigen: der einzige provider, der eine zusage ueber die latenz gemacht hat, war die selige eunet.

Jo, das waren noch Zeiten!
Um Zusagen geht es auch gar nicht, nur um branchen- und produktübliche Leistung. Und wenn UPC, Tele 2, LiWeSt, AON (wie auch immer das jetzt heißen mag) alle ungefähr die selben Werte liefern und nur Silver Server aus der Reihe fällt, ...

[fallenguru]

Editieren ist nicht mehr, dann halt so:

Um Zusagen geht es auch gar nicht, nur um branchen- und produktübliche Leistung. Und wenn UPC, Tele 2, LiWeSt, AON (wie auch immer das jetzt heißen mag) alle ungefähr die selben Werte liefern und nur Silver Server aus der Reihe fällt, ...

Da paßt das Preis/Leistungsverhältnis einfach nicht mehr. 16/1 ADSL best effort gibt's laut Geizhals um €140 für's 1. Jahr, da erwarte ich mir um €450 schon überdurchschnittliche Qualität.

[local.host]

DIr ist schon klar das beim DE-CIX (afaik) alle IP's auf die Colo in Frankfurt geriped sind oder ? Ich hätte auf die schnelle keine DE-CIX IP gefunden die auf das InterXion in Wien läuft, dort ist aber definitiv der DE-CIX Knoten den die .at ISP's verwenden

Bist du dir echt und ehrlich wirklich gaaaaaanz ganz sicher was du sagen wolltest?

[local.host]

die selige eunet.

Leichenfledderer!