[Fremdverschulden] Täuscht K.D. nun auch Speedtests vor?

[RcRaCk2k]

*** UPDATE *** UPDATE *** UPDATE *** UPDATE *** UPDATE *** UPDATE ***
ANSCHEINEND HAT KABEL DEUTSCHLAND NICHTS MIT DEM PROBLEM ZU TUN
*** UPDATE *** UPDATE *** UPDATE *** UPDATE *** UPDATE *** UPDATE ***

Hallo Leute!

Ich habe nun mal wieder was brisantes entdeckt, glaube ich zumindest

Ich betreibe in mehreren Rechenzentren eigene Co-Locations mit eigener Anbindung an die Core-Router der jeweiligen Standorte. Die Standorte sind mit 30 GBit/s an den Austauschknoten DE-CIX angebunden. Wir selber haben in unserer Cabinet einen 1 GBit/s Uplink der nicht mal zu 10% ausgelastet ist.

Ich setze von zuhause aus gerade ein paar neue Server auf, die nächste Woche in Nürnberg zur Unterstützung unseres Clusters online gehen sollen und lade mir gerade einige Test-Daten von den Servern aus Nürnberg herunter, wo ich diese erschreckende Neuigkeit entdeckt habe.

Meine Tests:
Download von meinem Server via RSYNC lief nur mit bis zu 600 kByte/s (4'800 kBit/s / 4.8 MBit/s)

Code: Alles auswählen

 bwm-ng v0.6 (probing every 0.500s), press 'h' for help
  input: /proc/net/dev type: rate
  \         iface                   Rx                   Tx                Total
  ==============================================================================
               lo:           0.00 KB/s            0.00 KB/s            0.00 KB/s
              wan:         529.37 KB/s           14.67 KB/s          544.04 KB/s
              lan:           0.00 KB/s            0.00 KB/s            0.00 KB/s
  ------------------------------------------------------------------------------
            total:         529.37 KB/s           14.67 KB/s          544.04 KB/s

Danach habe ich eine Datei von meinem Server im HTTP-Protokoll (unverschlüsselt) heruntergeladen:
Download pro Sekunde bei einem Socket: 384 kByte/s (3'072 kBit/s / 3.0 MBit/s)
Download pro Sekunde bei 5 Sockets: 1'482 kByte/s (11'856 kBit/s / 11.9 MBit/s)
Download pro Sekunde bei 10 Sockets: 1'982 kByte/s (15'856 kBit/s / 15.9 MBit/s)

Mein persönliches Fazit: Mit steigender Anzahl der Socket-Verbindungen wurde die Geschwindigkeit immer besser, jedoch stieg sie nicht proportional mit der Anzahl der Sockets an. Rückschlüsse auf einen Flaschenhals sind nicht gegeben, denn bei einer vollen Leitung können selbst mehrere Socket-Verbindungen keine Besserung bringen. Hier arbeitet QoS im Hintergrund.

Ich hatte explizit HTTP als Übertragung getestet, da laut meiner eigenen Analyse HTTP bei Kabel-Deutschland bevorzugt behandelt wird und alles was nicht dem HTTP-Protokoll entspricht automatisch in eine QoS Queue fällt... Sprich "Transport != HTTP >> Drosselung". Dennoch unterlag dieses Mal der HTTP-Download ebenfalls dem QoS.

Folgende Route wurde bei den Tests passiert:
Kabel-Deutschland Router: 80.81.193.249
Core-Backbone Router: 80.81.192.187
Standort: DE-CIX Frankfurt IXP, Lindleystrasse 12, D-60314 Frankfurt

Route von Freilassing ins RZ Nürnberg:

Code: Alles auswählen

HOST: www                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. fritz.box                     0.0%    50    0.6   0.6   0.5   0.7   0.0
  2. 83-169-168-42-isp.superkabel  0.0%    50    6.8   8.2   4.8  18.4   2.5
  3. 83-169-135-190-isp.superkabe  0.0%    50   11.4  13.5   9.5  58.0   7.1
  4. 83-169-128-201-isp.superkabe  0.0%    50   11.4  14.4   9.9  57.4   7.1
  5. 83-169-128-197-isp.superkabe  0.0%    50   17.0  19.0  16.2  26.2   1.9
  6. 83-169-129-57-isp.superkabel  0.0%    50   17.6  30.1  15.3 277.1  44.6
  7. xae0-499.fra20.core-backbone  0.0%    50   78.2  34.5  26.8  86.4  13.6
  8. xae1-2004.nbg10.core-backbon  0.0%    50   31.1  36.7  29.7  93.9  12.4
  9. vlan4019.access5.core-backbo  0.0%    50   29.0  32.2  28.6  49.5   3.4
 10. de-nbg-et0-0-r1.rix.rsm-conn  0.0%    50   29.7  31.8  29.6  36.9   1.4

Route vom RZ Nürnberg nach Freilassing:

Code: Alles auswählen

HOST: de-nbg-et0-0-r1             Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. nbg-et0-upl.rsm-connect.net   0.0%    50    0.3   0.4   0.3   1.7   0.3
  2. xae0-4026.nbg20.core-backbon  0.0%    50    0.1   3.9   0.1  48.8  11.7
  3. xae0-2004.fra20.core-backbon  0.0%    50    3.3   6.5   3.3  61.2  11.4
  4. f-rues-rt-peer-1.kabel-bb.de  0.0%    50    4.8   7.8   4.0 108.6  16.3
  5. 83-169-129-70-isp.superkabel  2.0%    50    5.1   5.2   4.3   6.3   0.4
  6. 83-169-128-109-isp.superkabe  0.0%    50   19.8  19.9  19.4  20.5   0.3
  7. 83-169-128-194-isp.superkabe  6.0%    50   20.7  24.3  19.7 164.9  21.4
  8. 83-169-134-187-isp.superkabe  0.0%    50   35.1  35.1  34.7  35.5   0.2
  9. 188-195-76-77-dynip.superkab  0.0%    50   31.2  31.9  29.4  40.2   2.2

Jetzt kommt aber das Beste:
Der IP-Plus Speedtest bestätigt mir eine Verbindung von 30'527 kBit/s (31 MBit/s).
[ externes Bild ]

Folgende Route wurde bei dem Speed-Tests passiert:
Kabel-Deutschland Router: 80.81.193.249 (meine Vermutung, hervorgehend aus dem IP-Plus Traceroute AS3303)
IP-Plus Router: 80.81.193.183
Standort: DE-CIX Frankfurt IXP, Lindleystrasse 12, D-60314 Frankfurt

Route von Freilassing zum IP-PLUS Speedtest-Server

Code: Alles auswählen

HOST: www                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. fritz.box                     0.0%    50    0.5   0.6   0.5   0.7   0.0
  2. 83-169-168-42-isp.superkabel  0.0%    50    7.4   7.7   5.0  12.8   1.8
  3. 83-169-134-190-isp.superkabe  6.0%    50   12.3  14.8   9.3 153.1  20.7
  4. 83-169-128-193-isp.superkabe  0.0%    50   22.9  22.5  20.5  25.2   1.2
  5. 83-169-128-110-isp.superkabe  0.0%    50   39.0  37.7  35.1  40.0   1.3
  6. 83-169-128-65-isp.superkabel  0.0%    50   26.4  34.5  24.9 242.9  35.8
  7. decix2.ip-plus.net            0.0%    50   27.3  34.3  25.6 216.1  27.6
  8. speedy-de.ip-plus.net         0.0%    50   26.3  28.7  25.1  56.7   5.3

Route von IP-PLUS AS3303 nach Freilassing

Code: Alles auswählen

1  164.128.248.1 (164.128.248.1)  0.552 ms  0.407 ms  0.309 ms
 2  164.128.248.12 (164.128.248.12)  0.457 ms  0.352 ms  0.459 ms
 3  i79zhh-000-gig1-1.bb.ip-plus.net (138.187.131.237)  0.720 ms  0.738 ms  0.719 ms
 4  i79zhh-005-gig3-0x204.bb.ip-plus.net (138.187.131.193)  0.974 ms  1.011 ms  0.837 ms
 5  i79zhh-025-ten0-0-0-1.bb.ip-plus.net (138.187.129.141)  0.851 ms  0.754 ms  0.720 ms
 6  i00dcx-015-por11.bb.ip-plus.net (138.187.130.97)  7.969 ms  7.982 ms  8.036 ms
 7  f-rues-rt-peer-1.kabel-bb.de (80.81.193.249)  8.948 ms  8.775 ms  9.051 ms
 8  83-169-129-70-isp.superkabel.de (83.169.129.70)  9.085 ms  9.464 ms  8.938 ms
 9  83-169-128-109-isp.superkabel.de (83.169.128.109)  25.306 ms  24.904 ms  25.047 ms
10  83-169-128-194-isp.superkabel.de (83.169.128.194)  24.949 ms *  24.590 ms
11  83-169-134-187-isp.superkabel.de (83.169.134.187)  39.532 ms  40.189 ms  39.243 ms
12  188-195-76-77-dynip.superkabel.de (188.195.76.77)  33.788 ms !X  34.856 ms !X  33.660 ms !X

Mein persönliches Fazit: Kabel-Deutschland priorisiert das Netz von IP-PLUS AS3303 bzw. den Subnetz-Bereich für den IP-PLUS Speedserver um schönere Ergebnisse beim Kunden zu erhalten und sich damit aus der Affäre zu ziehen, und die Probleme an die Content-Lieferanten im Hintergrund abzuwälzen.

Was Kabel-Deutschland damit für einen Sinn- und Zweck verfolgt ist mir bis dato noch unklar. Denn die Bandbreite steht, wie man sieht zur Verfügung.

Die Beiden Tests zum Speedtest-Server von IP-PLUS, sowie meine Downloads aus dem Core-Backbone Netzwork sind gleich zu setzen, denn der DOWNSTREAM (das ist die Route vom Server -> Freilassing) passiert immer die gleichen Router ab dem DE-CIX Internet-Austausch-Knoten.

Dass es bei Core-Backbone zu einer Überlastung der Strecke NÜRNBERG -> FRANKFURT AM MAIN kommt, denke ich nicht. Denn Core-Backbone verwendet kein QoS und in diesen Tests ist klar der Einsatz eines Quality-of-Service zu erkennen (mehrere Downloads ergeben einen höheren Speed - TCP-Data Fair-Queueing).

Irgendwie ist dem Verein nicht mehr zu trauen.

Grüße,
Michael.

[EdeVau]

Moin Michael,
ich kann das nicht so technisch nachweisen wie Du mangels entsprechender Mittel, aber
mein Bauchgefühl sagt(e) mir das schon lange.
Zumal man bei allen Test immer unterschiedliche stark abweichende Ergebnisse bekommt, Schätzeisen halt.

[Thyrael]

Ich hab gerade mal nen HTTP Download von K-Files getestet, Ergebnis, 3,5 - 3,7MB/s, und die auch mehrmals. Die KDG mag zwar ihre Probleme haben aber ich glaube nun nicht das sie deswegen die Speedtests manipulieren nur um die Kunden mit Speedproblemen abzuweisen.

P.S.: Der Download war nur mit einer einzelnen Verbindung.

[RcRaCk2k]

K-Files läuft auch über DE-CIX (vsenet.de / teresto.net) zu teliko GmbH. Das würde zumindest schon mal ein Anhaltspunkt darauf sein, dass der DE-CIX nicht in solchem Maße priorisiert wird, wie ich mir das gedacht habe. Leider konnte ich aber keine Backroute für das AS29037 finden, die den Routenverlauf über DE-CIX beweisen würde, denn wer weiß, vielleicht wird der Downstream (dein Download) nicht über DE-CIX gerouted.

[Bubblegum]

Der Sachverständige Leser dieser Protokolle und Fachmann in diesem Bereich wird mir die sicher für Ihn "dumme" Frage verzeihen:

Täuscht KD wirklich was vor oder werden evt bei den von KD durchgeführten Tests vorgebene Verbindungen genutzt, auf die der Normaluser nicht zugreifen kann?

[Thyrael]

Naja, ich denke z.B. der Speedtest auf der Kabel D Seite wird netzintern laufen, also im Kabel D-eigenen Netz und somit könnte dieser Test u.U. höhere Werte anzeigen als ein Test außerhalb des Kabel D Netzes bzw. ein Download von einem externen Server.

Das KDG absichtlich bestimmte Routen priorisiert können wir nur vermuten, wir haben ja keinen Einblick in die Konfiguration des Netzes und der Router. Ich könnte mir vorstellen das der Test von R2 (ich kann mir den kompletten Namen nicht merken, daher die Abkürzung ) unter die allgemeine Drosselung fällt, es ist ja immerhin Wochenende?

[VBE-Berlin]

R2 (ich kann mir den kompletten Namen nicht merken, daher die Abkürzung )

Vielleicht kann ihn ja ein Admin zu R2D2 umbenennen. Da kann man sich was drunter vorstellen und es auch aussprechen

MB-Berlin

[amax]

Jedenfalls ist die KDG wohl mit mehreren peers bei DE-CIX vertreten.
Meine Backroute von der AS 3303 geht über i00dcx-015-por11.bb.ip-plus.net (138.187.130.97)
zu f-rebs-rt-peer-1.kabel-bb.de (80.81.192.249)
und wird schon dort aufgedrösselt.........

Aber der IP plus Test war schon immer gut angebunden. Daher nutze ich den auch schon seit Jahren.

[Silverio]

Für Gebiete und Anschlüsse mit hoher Auslastung/begrenzter Bandbreite mag das ja was ausmachen.
Ich persönlich merke aber keine Bevorzugung. Allerdings bin ich wohl einer der wenigen Kunden, die fast immer Maxspeed bei KD erreichen. (wenn man mal von den lahmen DNS und schlecht angebundenen Netzen absieht...)

Bei mir erreichen fast immer alle Speedtest die Max-Bandbreite von 32/2 MBit/s.
Nur der KD-eigene Speedtest zeigt im Upload quasi fix immer nur maximal 1,6 MBit/s an...

Auch downloads von bekannten, schnellen Servern (microsoft.com, hp.com, rapidshare.de) laufen zumindest mit Downloadmanager und 4 Segmenten fast immer Fullspeed, selbst Abends.
Ebenso ein Download von Suse Linux erreicht bis 18 Uhr knapp 4MB/sec. Danach ist natürlich Ende bis nach Mitternacht.

Was will ich damit sagen?
Nun, in ausgelasteten Gebieten mag es ja was bringen, dass bestimmte Dienste oder Netze bevorzugt werden. Bei mir macht sich das quasi nicht bemerkbar. Im Gegenteil, der Hauseigene KD-Speedest bringt mir die langsamsten Ergebnisse.

[RcRaCk2k]

Mich wundert nur, dass mir der ip-plus Server Speedtest 30MBits beglaubigt, während ich über die gleiche Route beim Download aber nur 368kBit erreiche (0,36 MBit) Das ist nicht normal

vorgebene Verbindungen genutzt, auf die der Normaluser nicht zugreifen kann?

vorgegeben, das wäre MPLS als Routing Instrument. Ich denke aber, dass K.D. im kompletten Netz (der Übersichthalber) auf Routen-Nähe (Route mit den wenigsten Hops ist die Beste) wie z.B. OSPF, ISIS, BGP usw. setzt. Also sollten die Routen immer die Selben bleiben.

Jedenfalls ist die KDG wohl mit mehreren peers bei DE-CIX vertreten.

Das hoffe ich auch Das nennt man dann 1. Load-Balancing und 2. High-Availability. Zudem denke ich, dass je nach Herkunft der User die Routenverläufe im DE-CIX sich bereits, wie in deinem Fall, unterscheiden.

Für Gebiete und Anschlüsse mit hoher Auslastung/begrenzter Bandbreite mag das ja was ausmachen.

Das ist ja gerade das interessante. 30MBit über den Speedtest. Also ist das Netz nicht ausgelastet und hat auch keine begrenzte Bandbreite, was solch ein QoS-Verhalten notwendig machen würde.

Ich hoffe mal, dass das Problem außerhalb des Netzes von K.D. hinter DE-CIX auftritt und dass K.D. keine Spielereien am Netz treibt, die total sinnlos sind.