Dsl-Geschwindigkeit
Hans-Peter
An welcher Schraube kann/muss/sollte ich noch drehen
um an die versprochenen 16000 kbit/s heranzukommen.
Meine gemessenen Werte mit Speedtest ergaben:
Download 11 246 kbit/s
Upload 869 kbit/s
Ich arbeite mit Windows XP und habe den
Router der T-com W701v
Besten Dank für Hinweise.
Hans-Peter
Joseph Terner
> Endlich DSL 16000 der T-com meine Frage an die Experten:
>
> An welcher Schraube kann/muss/sollte ich noch drehen
> um an die versprochenen 16000 kbit/s heranzukommen.
Die TAL kürzer machen, den Querschnitt erhöhen, die anderen
ADSL2+-Anschlüsse im Hauptkabel abschalten. Kurzum: Dämpfung runter,
Signal-Rausch-Verhältnis hoch.
ciao, Joseph
Michael Landenberger
> Endlich DSL 16000 der T-com meine Frage an die Experten:
>
> An welcher Schraube kann/muss/sollte ich noch drehen
> um an die versprochenen 16000 kbit/s heranzukommen.
Einerseits schließe ich mich an die Aussagen meiner Vorposter an. Speziell
bei ADSL2+ musst du wegen der leitungsabhängigen, dynamischen Aushandlung
der DSL-Bandbreite mit allen möglichen Werten rechnen, die Telekom
garantiert bei T-DSL 16000 lediglich 6600 kbit/s. Nichtsdestotrotz gibt es
doch noch eine "Schraube", an der du drehen kannst, nämlich das TCP Receive
Window (RWIN). Du kannst auf <http://www.speedguide.net/analyzer.php> deine
derzeitigen Einstellungen überprüfen (achte dabei besonders auf das Feld
"bandwith * delay product) und mit dem Freeware-Tool TCP Optimizer ggf.
korrigieren. Den TCP Optimizer kannst du auf
<http://www.speedguide.net/downloads.php> herunterladen.
Gruß
Michael
Michael Landenberger
> Michael Landenberger schrieb:
>
>> Nichtsdestotrotz gibt es doch noch eine "Schraube", an der du
>> drehen kannst, nämlich das TCP Receive Window (RWIN).
>
> Nach eigener praktischer Erfahrung, nur in homöopathisches Dosen. ;-)
> Eine gegenteilige, nachvollziehbare Angabe aus der Praxis wäre recht
> interessant.
Ich weiß leider nicht, was du unter "nachvollziehbar" verstehst. Ein
konkretes Beispiel aus der Praxis kann ich allerdings liefern: meines
Wissens liegt der Default-RWIN-Wert bei Windows XP bei 65535. Nach
Optimierung mittels TCP Optimizer lag der RWIN-Wert für 4000 kbit/s bei
257004. Bei der 11-Mbit/s-WLAN-Verbindung meines Laptops führte diese
Änderung bei ansonsten gleichbleibenden Randbedingungen dazu, dass ich statt
vorher nur 2500 kbit/s nun auch drahtlos die volle DSL-Bandbreite von 4000
kbit/s nutzen konnte. Eine derartige Verbesserung würde ich nicht als
"homöopathisch" bezeichnen ;-) Auch nach der Steigerung der Bandbreite
meines Alice-Anschlusses von 4 auf 16 MBit/s führte erst eine erneute
Anwendung des TCP Optimizers (diesmal auf eine LAN-Verbindung) dazu, dass
ich die volle DSL-Bandbreite nutzen konnte. Mit den für 4 MBit/s optimierten
Einstellungen lag der Datendurchsatz dagegen etwas darunter (bei ca. 13
MBit/s). An der Tatsache, dass 11 MBit/s-WLAN eine 16 MBit/s-Verbindung
ausbremst, kann der TCP Optimizer allerdings auch nichts ändern ;-)
Apropos WLAN: der OP sollte natürlich seine Speedtests auf jeden Fall mit
einer kabelgebundenen LAN-Verbindung durchführen. WLAN kann auch mit 54
MBit/s je nach Empfangssituation zum Nadelöhr werden.
Gruß
Michael
Ganxta Congstar
> An welcher Schraube kann/muss/sollte ich noch drehen
> um an die versprochenen 16000 kbit/s heranzukommen.
du solltest erstmal paar grundlegend physikalische angaben zu deiner
breitbandsituation machen.
du solltest den zustand der dsl-strecke auf unterster ebene auslesen,
und nicht (nur) highlevel traffictests machen die durch eine unzahl an
dingen beeinflussbar sind.
die unterste ebene musst du messen, wenn die nur entsprechende werte
ausgibt, dann ist kein wunder dass nicht mehr traffic durch die leitung
geht.
jenach modem/router bzw mit diversen hilfstools kann man den sog.
synchronisations-zustand des dsl-modems (endgeraetes beim kunden) mit
der gegenstelle (dslam) des telekommunikationsanbieters (in der
vermittlungsstelle) anzeigen, auslesen, festellen.
das ist der erste schritt den du beschreiten musst, und erst spaeter
folgen die higherlevel massnahmen falls ueberhaupt notwendig.
Ralph A. Schmid, dk5ras
>>
>>An welcher Schraube kann/muss/sollte ich noch drehen
>
>An der Realismus-Schraube.
Das sowieso :)
>>um an die versprochenen 16000 kbit/s heranzukommen.
Den W701V gegen einen W700V austauschen.
>>Meine gemessenen Werte mit Speedtest ergaben:
>>
>>Download 11 246 kbit/s
>>Upload 869 kbit/s
>
>Sind doch prima Werte. Lass es so, und drück die Daumen, daß die
>Nachbarn nicht zu bald auch DSL bestellen. Dann gehts stetig
>abwärts...
Abgesehen davon, ich würde an seiner Stelle mal im Menu des Routers
nachsehen, wie er synchronisiert - nur das zählt, nicht die
Schätzungen irgendwelcher speedtester.
Ralph.
Ralph A. Schmid, dk5ras
>Nach eigener praktischer Erfahrung, nur in homöopathisches Dosen. ;-)
Von um 200 KByte/sec auf 650 KByte/sec bei T-DSL 600 nenne ich nicht
homöpahisch. So gewesen bei mir. Ebenso jetzt bei VDSL-50 an menem
server im upstream von 300 KByte/sec auf gut 1 MByte/sec...
Andreas Erber
> Ralph A. Schmid, dk5ras schrieb:
>
>>> Nach eigener praktischer Erfahrung, nur in homöopathisches Dosen.
>>> ;-)
>
>
>> Von um 200 KByte/sec auf 650 KByte/sec bei T-DSL 600 nenne ich nicht
>> homöpahisch. So gewesen bei mir. Ebenso jetzt bei VDSL-50 an menem
>> server im upstream von 300 KByte/sec auf gut 1 MByte/sec...
>
> gewisse Tuningtools etwas bewirken können. Kann es aber nicht auch
> sein, daß diese Rechner zuvor 'kaputtgetunt' wurden oder ähnliches?
Nein das TCP Receive Window ist bei Windows standardmäßig für
Breitbandinternetverbindungen zu klein eingestellt. Evtl. hast du das
Bedürfnis mal was über Fensterprotokolle wie TCP nachzulesen um zu verstehen
warum diese Zahl so wichtig ist. Es kommt dabei vorallem auch auf die
Laufzeit der Pakete (Im Lan ist das Window nämlich nicht zu klein, hier sind
die Latzen niedrig genug) an und es hat auch was damit zu tun das TCP die
Eigenschaft hat jedes Paket mit einem ACK zu bestätigen.
http://de.wikipedia.org/wiki/Transmission_Control_Protocol
LG Andy
Gitano
Hash: SHA1
Michael Landenberger schrieb:
> Nichtsdestotrotz gibt es doch noch eine "Schraube", an der du drehen
> kannst, nämlich das TCP Receive Window (RWIN). Du kannst auf
> <http://www.speedguide.net/analyzer.php> deine derzeitigen Einstellungen
> überprüfen (achte dabei besonders auf das Feld "bandwith * delay
> product) und mit dem Freeware-Tool TCP Optimizer ggf. korrigieren.
Meine Ergebnisse von dieser Seite:
MSS: 1452
MTU: 1492
TCP Window: 5840 (NOT multiple of MSS)
RWIN Scaling: 2
Unscaled RWIN : 1460
Reccomended RWINs: 63888, 127776, 255552, 511104
BDP limit (200ms): 234kbps (29KBytes/s)
BDP limit (500ms): 93kbps (12KBytes/s)
Tatsächliche Einstellungen (default, unverändert):
/proc/sys/net/core/rmem_default - 110592
/proc/sys/net/core/rmem_max - 110592
Mein Anschluß (DSL-2000) laut Fritzbox:
ATM-Datenrate kBit/s 2304 224
Nutz-Datenrate kBit/s 2087 203
Downloadgeschwindigkeit eines Linux-Images (693 MB):
218 kBit/s
Paßt irgendwie nicht so recht zur Theorie ...?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHG1CghZWiQsqYS8oRAhG+AJ9B+cL6QCZwoAkAgXb0dMqzMrUCjgCdGaV4
DQThJl13Kc0j0xpUqOcJGso=
=dXo+
-----END PGP SIGNATURE-----
Michael Landenberger
> Meine Ergebnisse von dieser Seite:
>
> MSS: 1452
> MTU: 1492
> TCP Window: 5840 (NOT multiple of MSS)
> RWIN Scaling: 2
> Unscaled RWIN : 1460
> Reccomended RWINs: 63888, 127776, 255552, 511104
> BDP limit (200ms): 234kbps (29KBytes/s)
> BDP limit (500ms): 93kbps (12KBytes/s)
>
> Tatsächliche Einstellungen (default, unverändert):
>
> /proc/sys/net/core/rmem_default - 110592
> /proc/sys/net/core/rmem_max - 110592
Keine Ahnung, warum diese Einstellungen nicht im Analyzer erscheinen. Bin
auch nicht so der Linux-Experte ;-) Leider unterstützt der TCP Optimizer nur
Windows.
> Mein Anschluß (DSL-2000) laut Fritzbox:
>
> ATM-Datenrate kBit/s 2304 224
> Nutz-Datenrate kBit/s 2087 203
>
> Downloadgeschwindigkeit eines Linux-Images (693 MB):
>
> 218 kBit/s
>
> Paßt irgendwie nicht so recht zur Theorie ...?
Doch, schon. Mit nur einem Zehntel der Soll-Datenrate würde ich mich
jedenfalls nicht zufrieden geben. Außerdem passen die 218 kbit/s sehr gut
zum "BDP Limit (200ms)" von 234 kbit/s.
Gruß
Michael
Gitano
Hash: SHA1
Michael Landenberger schrieb:
>> Tatsächliche Einstellungen (default, unverändert):
>>
>> /proc/sys/net/core/rmem_default - 110592
>> /proc/sys/net/core/rmem_max - 110592
>
> Keine Ahnung, warum diese Einstellungen nicht im Analyzer erscheinen.
> Bin auch nicht so der Linux-Experte ;-)
Entspricht m. W. dem besagten 'RWIN'.
> Leider unterstützt der TCP Optimizer nur Windows.
Ein echter Pinguin macht das 'zu Fuß'. ,-)
>> Downloadgeschwindigkeit eines Linux-Images (693 MB):
>>
>> 218 kBit/s
>>
>> Paßt irgendwie nicht so recht zur Theorie ...?
>
> Doch, schon. Mit nur einem Zehntel der Soll-Datenrate würde ich mich
> jedenfalls nicht zufrieden geben. Außerdem passen die 218 kbit/s sehr
> gut zum "BDP Limit (200ms)" von 234 kbit/s.
Argh ... Das sollte natürlich 218 kByte/s heißen (53 min. Downloadzeit).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFHG2P9hZWiQsqYS8oRAt/sAJ43vS7DKv+8NKhur7l6pkGwwg833ACdFerL
wC661pAcoAUacXlKW6DMtNs=
=2+Et
-----END PGP SIGNATURE-----
Ralph A. Schmid, dk5ras
>Nun, dann will ich einmal daraus lernen, daß bei bestimmten Systemen
>gewisse Tuningtools etwas bewirken können. Kann es aber nicht auch
>sein, daß diese Rechner zuvor 'kaputtgetunt' wurden oder ähnliches?
Denkbar; da ich nicht alle paar Monate mein OS neu installiere,
handelte es sich teilweise um jahrealte Installationen, da kann schon
mal was vom default abweichen, oder noch alte Defaults von Microsoft
haben, die bei neuen Installationen längst verbessert sind, aber auch
durch updates nicht angepaßt werden.
>Mathias,
>der zwar z.Z. auch technische Zugangsproblemchen hat, welche die
>Telekom nicht beseitigen konnte, diese aber nichts mit der
>Geschwindigkeit zu tun haben, sondern mit Inaktivitätstrennungen _nach_
>der obligatorischen Zwangstrennung. Im Internet (allgemein) sind keine
>Lösungen zu finden.
Inaktivitätstrennung habe ich rein theoretisch auch, aber ich da hier
keine Inaktivität herrscht, trifft mich das nicht :)
Ralph.
Ralph A. Schmid, dk5ras
>BTW: Wer große Dateien lädt, sollte ein Programm nutzen, welches
>mehrere Verbindungen dorthin aufbaut und den Download splittet, das
>hilft oft (bei guter Anbindung des Servers und je nach den dortigen
>Einstellungen), die mögliche DSL-Geschwindigkeit auch zu erreichen.
Und es müllt die Leitung des servers zu, dazu sehe ich es nicht ein,
warum ich ein Programm dafür besorgen soll, was eigentlich das OS
können muß :)
Ralph.
Andreas Erber
Außerdem nutzt das nichts. Die TCP Verbindung wird ja nicht von dem Programm
verwaltet sondern vom OS. Ist das Receive Window zu klein bgrenzt es die
Bandbreite für alle Anwendungen und Verbindungen. Programme können den TCP
Stack des OS ja nicht einfach umgehen.
LG Andy