Seite 5: VDSL-Test

Inhaltsverzeichnis

Ganz schnell

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

Bleifuß

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.

VDSL-Eckwerte
	Datenrate (MBit/s)	Spitzendurchsatz (KByte/s)
Senderichtung	5	580
Empfangsrichtung	25	2800

Download-Vergleich
Anschlussart	Zeit (Minuten)
DSL 25000	1,11
DSL 6000	4
DSL 2000	10
DSL 1000	21
ISDN	347
Modem 56K	540

Die 161 MByte große Datei T-Online_6.0.exe von einem T-Online-Server herunterzuladen dauert an einem aktuellen VDSL-Anschluss nur rund 70 Sekunden.

Kooperation hilft

Schaltet man währed des Downloads hochauflösendes Fernsehen ein, geht der Durchsatz sowohl mit als auch ohne Download-Manager zurück, weil der Router den IPTV-Stream gegenüber dem Download priorisiert; dafür muss der Media-Receiver mit dem Router über LAN-Port 3 oder 4 verbunden sein. An Port 1 und 2 erfolgt keine Priorisierung, sodass Fernsehbilder durch Downloads ausgebremst werden. Bei Telefonaten über den SIPClient des Routers traten während der schnellen Downloads weder spürbare Verzögerungen noch Aussetzer auf. Auch Skype-Telefonate per WLAN waren unter diesen Umständen ohne große Störungen möglich. Im Test stieg die Latenz von 40 Millisekunden ohne Download auf rund 66 Millisekunden mit Download und die Fehlerrate stieg von 0 auf rund 1,2 Prozent. Störend fiel die Latenzzunahme nicht auf. Lediglich geringe Verzerrungen und seltene, sehr kurze Aussetzer waren zu vernehmen.