Reale Bandbreite vs. angezeigte Bandbreite

Hallo THX1138.79,

ich habe gerade deinen Beitrag gefunden.

Ein Speedtest ist immer so eine Sache hierbei muss auch die Verbindung zum jeweiligen Server berücksichtigt werden. Generell liegt auch diese Messung im Rahmen einer VDSL 50-Leitung von uns. Von daher kann ich aktuell keinen Fehler feststellen.

Ich wünsche dir natürlich immer einen vollen Sync und einen schönen Nachmittag.

Viele Grüße

Natalie P. von Telekom hilft

Deine Leitung ist in der Tat perfekt. Die gemessenen Abweichungen sind marginal und höchstwahrscheinlich durch Engpässe in den involvierten IP-Backbones und nicht etwa auf die letzte Meile zurückzuführen.

Wie Du Dir vielleicht denken kannst, hat Dein Provider keine eigenen Leitungen zu jedem Server auf dieser Welt, sondern ist auf die Netze Dritter angewiesen. Als praktisches Beispiel hier mal eine Routenverfolgung von einem VDSL-Anschluß im Telekom-Backbone zum Webserver des CS Breitband GmbH, deren Speedtest-Server Du anscheinend benutzt hast.

tracert [url]www.cs-breitband.de[/url] 
 
Routenverfolgung zu [url]www.cs-breitband.de[/url] [91.106.128.143] 
über maximal 30 Hops: 
 
  1    <1 ms    <1 ms    <1 ms  fritz.box [10.1.1.1] 
  2     6 ms     6 ms     6 ms  217.0.117.178 
  3     8 ms     7 ms     7 ms  87.186.197.66 
  4     9 ms     9 ms     9 ms  217.239.48.178 
  5    11 ms    10 ms     9 ms  ffm-b12-link.telia.net [213.248.103.169] 
  6    59 ms     9 ms     9 ms  ffm-bb1-link.telia.net [62.115.142.24] 
  7    17 ms    17 ms    35 ms  hbg-bb1-link.telia.net [213.155.135.145] 
  8    21 ms    25 ms    21 ms  hbg-b1-link.telia.net [213.155.135.83] 
  9    17 ms    17 ms    17 ms  ccbreitband-ic-154985-hbg-b1.c.telia.net [195.12.254.210] 
 10    22 ms    22 ms    22 ms  p08-l08-m1.routing.csb-net.de [91.106.128.117] 
 11    17 ms    17 ms    17 ms  vsm-m1.routing.vsm.sh [91.106.128.1] 
 12    22 ms    22 ms    22 ms  [url]www.csb-net.de[/url] [91.106.128.143] 
 
Ablaufverfolgung beendet.

Wie Du siehst läuft die Verbindung über 11 sog. Hops. Davon sind 2-4 im Machtbereich der Telekom, die den Verkehr in Frankfurt an Telia Sonera übergibt. Telia Sonera transportiert den Verkehr dann nach Hamburg (Hops 5-9) und in Hamburg übergibt Telia den Datenverkehr dann an CS, die den Verkehr über mindestens drei weitere Verbindungsstrecken zum Zielserver (12) transportieren.
Sollte auf irgendeiner dieser elf Verbindungsabschnitte ein Engpaß auftreten, erreichst Du Deine 50Mbps schon nicht mehr und die Telekom hat keinen direkten Einfluß darauf, was nach Hop 4 passiert.
Tatsächlich können auf obiger Route übrigens noch mehr Hops liegen, die jedoch aufgrund der Verwendung von MPLS transparent und daher für den Endkunden nicht sichtbar sind.

Um alle Flaschenhälse außerhalb des Telekom-Backbones zu umgehen, solltest Du den Speedtest daher über einen Server im Telekom-Backbone durchführen, z.B. über http://speedtest.t-online.de

Ansonsten empfiehlt es sich für Speedtests immer Server in Frankfurt statt solche auf dem Land zu verwenden und zwar möglichst von einem großen Provider mit entsprechend breitandigen Backbone bzw. Cross-Connects. Erstens läuft ein Großteil des Internetverkehrs über Frankfurt, da die meisten ISPs eine zentralistische Netztopologie mit Frankfurt als Zentrum haben und Dein Datenverkehr sowieso erst einmal nach Frankfurt fließt bevor er zurück nach Bad Oldesloe oder sonstwohin geroutet wird (siehe meine Routenverfolgung oben). Zweitens eliminiert man damit Engpässe auf der Strecke Frankfurt-Bad Oldesloe und drittens haben die Carrier in Frankfurt meist viel höhere Bandbreitenreserven als auf einer Fernstrecke, denn innerhalb Frankfurts bekommt man Dark Fibers nachgeschmissen während Kapazität auf Fernstrecken viel teurer ist.

Letztlich sei auch anzumerken, daß die Telekom zwar einen großzügig dimensionierten Backbone besitzt und sich berühmt diesen nicht zu überbuchen, jedoch erübrigt sich dieser Vorteil oft durch ihre selektiven Peering Policy. Die Telekom schaltet ihr Netz grundsätzlich nämlich mit niemandem zusammen, der für den anfallenden Traffic nicht teuer bezahlt, selbst wenn das Datenaufkommen im Up- und Downstream symmetrisch ist. Aufgrund des sehr hohen Preises, den die Telekom für IP-Transit in die magenta Netze aufruft, haben viele andere Anbieter gar keinen direkten Interconnect mit der Telekom (und gehen den Umweg über günstigere IP-Transit Provider, die ihrerseits günstiger bei der Telekom einkaufen) oder wenn doch, dann mit beschränkter Bandbreite um die Kosten unter Kontrolle zu behalten. Dieser Umstand macht den Performancevorsprung, den die Telekom im eigenen Backbone hat, oft wieder zu nichte.

Re: Reale Bandbreite vs. angezeigte Bandbreite

Zitat

Original geschrieben von THX1138.79
Laut der DSL-Informationen in meiner Fritz!Box 7490 ist eine Bandbreite von 50 Mb/s im Downstream und 10 Mb/s im Upstream ausgehandelt, siehe Abbildung unten. Die Leitungswerte sehen nach meiner Einschätzung gut aus.

Mache ich nun Speedtests über verschiedenste Server, komme ich stets auf maximal 47,77 Mb/s im Downstream und nur 8,9 Mb/s im Upstream. Der PC ist über ein LAN-Kabel mit dem Router verbunden. Anti Virus Software, Softwarefirewalls und andere Nutzer der Verbindung können als „bremsende Ursache“ bereits ausgeschlossen werden. Als Beispiele für eine größere Messreihe von Speedtests sollen die beiden Abbildungen dienen.

Alles anzeigen

Das sieht ganz normal aus!

Die Datenrate die im Routermenue angezeigt wird ist immer eine ATM-Datenrate und keine TCP/IP Datenrate. Dort die Protokolle hat man da etwas Verlust.

Die reale Nutzrate liegt meines Wissens im Normalfall immer zwischen 80-90%. Insofern ist alles in Ordnung.

Re: Re: Reale Bandbreite vs. angezeigte Bandbreite

Zitat

Original geschrieben von Anja Terchova
Die Datenrate die im Routermenue angezeigt wird ist immer eine ATM-Datenrate und keine TCP/IP Datenrate.

Bei VDSL2 kommt im Aggregationsnetz kein ATM mehr, sondern PTM-TC zum Einsatz, aber overhead entsteht jedenfalls.