Theoretisch kann ein VDSL-Modem bei 25 MBit/s brutto rund 3,2 MByte/s liefern (wir gehen bei 1 MBit von 1024 kBit aus – dann entsprechen 25 MBit/s = 3276,8 KByte/s) / VDSL50 >>> 6,4 MByte/s >>> 6375
Eine der spannendsten Fragen im Test war, wie schnell der VDSL-Anschluss Daten übertragen würde. Manche Fachleute sahen der Einführung der VDSLTechnik mit der Erwartung entgegen, dass sich die enorme Bandbreite kaum allein durch Surfen ausschöpfen ließe, weil es einfach zu wenige Server gibt, die schnell genug Daten liefern können. Theoretisch kann ein VDSL-Modem bei 25 MBit/s brutto rund 3,2 MByte/s liefern (wir gehen bei 1 MBit von 1024 kBit aus – dann entsprechen 25 MBit/s = 3276,8 KByte/s). Netto sind wegen Verwaltungsdaten rund fünf Prozent weniger zu erwarten. Messreihen bestätigten auch, dass der maximale Durchsatz längst nicht mit allen Servern im Internet erreichbar ist. Aber man findet leicht Gegenstellen, die 2 MByte/s und mehr liefern können. Dabei ist zu beachten, dass die meisten PCs für so enorm schnelle Anschlüsse nur unzureichend konfiguriert sind. Das äußert sich darin, dass der Download umso langsamer abläuft, je weiter der angezapfte Server netzwerktechnisch entfernt ist.
Die Ursache ist ein zu kleines Receive Window (RWIN), ein Puffer, der bei TCP/IP für den Datenempfang erforderlich ist. Je kleiner dieser Puffer ist, desto häufiger muss der Server warten, bis er Empfangsbestätigungen für die gesendete Datei erhält; ohne fortwährende Empfangsbestätigungen kann der Server nicht senden. Sinkender Durchsatz bei zunehmend entfernten Gegenstellen zeigte sich auch in unseren Messungen, etwa mit Servern in Japan. Schickt man Ping-Pakete nach Japan, dauert es rund 330 Millisekunden, bis die Antwort eintrifft (RTT, Round Trip Time). Belässt man das Receive Window zum Beispiel bei einem MacBook auf der Werkseinstellung (32.768 Byte), kommt trotz VDSL-Anschluss nur ein Durchsatz von rund 200 KByte/s zustande. Um die volle Download-Rate zu erreichen, muss das Receive Window so groß sein wie das Produkt aus der Datenrate des Anschlusses und der Round Trip Time. Oder anders gesagt: Wenn die RTT eine Sekunde beträgt,dann braucht man bei einer 25-MBit/s-Leitung ein 25 MBit großes Window.
Für den Telekom-Server software.t-online.de (RTT im Test 28 ms) ergibt sich am VDSL-Anschluss (3,2 MByte/s) eine Window Size von 91,75 KByte. Wenn die RTT zunimmt, etwa wegen weiter entfernter Server, braucht man ein noch größeres Window. Um für alle Fälle gewappnet zu sein und auch maximal entfernte Server im Ausland mit optimalen Einstellungen ansprechen zu können, sollte man die Window Size auf mindestens 330 Millisekunden anpassen, also auf rund 1 MByte erhöhen. Microsoft schreibt zur Window Size, dass dieser Wert unter Windows XP per Faustformel eingestellt wird:
12 x (MTU des Adapters – 40)
Das entspricht bei einer im DSLBereich üblichen MTU von 1492 Byte lediglich 17424 Byte – für Modem- und ISDN-Verbindungen genügt das, nicht aber für DSL-Anschlüsse. Um die Window Size bei XP zu vergrößern, öffnet man in Regedit den Bereich HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters. Die Window Size wird im Schlüssel TcpWindowSize im DWORD-Format eingetragen. Ist der Schlüssel nicht vorhanden, muss man ihn per Hand anlegen, sonst verwendet Windows Standardwerte. Es lohnt sich also, den Schlüssel anzulegen und den Wert großzügig einzustellen. Änderungen werden erst nach einem Neustart des Rechners aktiv. Wie sehr die Leistung der Breitbandanschlüsse den Vorstellungen mancher Entwickler davongeeilt ist, zeigt auch ein Beispiel aus der Macintosh-Welt. Apple hat im November 2005 ein Archiv namens BroadbandTuner veröffentlicht, das gerade zum Ziel hatte, die Leistung der Macs an Breitbandanschlüsse anzupassen: Es vergrößert das Receive Window auf 358.400 Byte. Mit dieser Einstellung lässt sich die Datei X11Update2006.dmg vom Apple-Server wsidecar.apple. com (RTT = 184 Millisekunden) immerhin mit rund 2 MByte/s laden. Stellt man das Receive Window passend für 25 MBit/s ein (bei Apple Receive Space genannt), kommt man schon in die Nähe des theoretischen Maximums:
sudo sysctl -w net.inet.tcp.recvspace=1075200
Zusätzlich sollte man bei solchen Window Sizes beachten, dass das Mac OS X mit dem von Haus aus reservierten Socket-Speicher nicht mehr auskommt. Man sollte ihn also entsprechend vergrößern:
sudo sysctl -w kern.ipc.maxsockbuf=2048000
Beide Einstellungen werden umgehend aktiv, ein Neustart ist nicht erforderlich. Damit waren Spitzenraten von rund 2,8 MByte/s möglich (49,68 MByte in 18 Sekunden).
Die kleinste Unstimmigkeit während der Übertragung drückt jedoch den Durchsatz deutlich. Wenn auch nur einer der am Transfer beteiligten Router überlastet ist, stockt die Übertragung sekundenlang, bis die Fehlerkorrekturmechanismen greifen. In der Praxis erreicht man die gemessenen Spitzenwerte bei großen Dateien also kaum durchgängig während des gesamten Downloads.
Zusätzlich können die Server hinsichtlich ihrer Sendeleistung eingeschränkt sein – beispielsweise, um angemessenen Durchsatz für mehrere Nutzer gleichzeitig liefern zu können oder um gleichzeitig andere Dienste ausführen zu können. So lieferte im Test der nur 26 Millisekunden entfernte FTP-Server ftp.t-online.de nicht mehr als 800 KByte/s. Mit einem Download-Manager kann man die bei solchen Servern eingerichtete Download-Beschränkung umgehen. Solche Programme laden über mehrere TCP-Verbindungen gleichzeitig verschiedene Teile einer Datei und setzen sie anschließend zusammen.
In Windows übernimmt die Anpassung der SG TCP Optimizer
OS X:
RWIN anpassen
VDSL25:
sudo sysctl -w net.inet.tcp.sendspace=1075200
sudo sysctl -w net.inet.tcp.recvspace=1075200
VDSL50:
sudo sysctl -w net.inet.tcp.sendspace=2150400
sudo sysctl -w net.inet.tcp.recvspace=2150400
Window Sizes vergrößern
VDSL25:
sudo sysctl -w kern.ipc.maxsockbuf=2048000
VDSL50:
sudo sysctl -w kern.ipc.maxsockbuf=4096000
wenn du die eingeben hast, dann sollte sich das direkt auswirken…
speichern kannst du die vDSL50 bzw vDSL25-Werte, in dem du einfach das
net.inet.tcp.sendspace=2150400 net.inet.tcp.recvspace=2150400 kern.ipc.maxsockbuf=4096000
in /etc/sysctl.conf schreibst…