Windows XP FTP server überschreibt tcp window size?

Hallo,

Netzaufbau
XP Prof FTP Server ---- 1 Mbit/s wireless -------- XP Prof, FTP client

Round Trip Delay ist ca 100ms, d.h. tcp window Size 0,1 * 1 Mbit = 12,5
Kbyte sollte ausreichen.
Nach ca 6kbyte stoppt der FTP server (tcp) und wartet ca 100ms auf
Acknowledge. Eine Vergrösserung der tcp Window-Einstellung hat keine Wirkung.
Durch dieses Verhalten werden nur ca 25Kbyte/s statt erwartete 125 Kbyte/s
übertragen. 2 FTP Sessions können in paralell gestartet werden.
Gesamtdurchsatz ist dann ca 50Kbyte/s.
Mit UDP können 1Mbit/s übertragen werden.

Ein ähnliches Problem is hier beschieiben - aber keine Lösung:
http://www.vad1.com/tcp-throughput-limit.html

Ãœberschreibt der WinXP FTP Server die tcp Window-Einstellung? Wenn ja, kann
man den FTP Server konfigurieren?

Grüsse, Mats

Mats <Mats@discussions.microsoft.com> schrieb:

Hallo Mats,

> Nach ca 6kbyte stoppt der FTP server (tcp) und wartet ca 100ms auf
> Acknowledge. Eine Vergrösserung der tcp Window-Einstellung hat keine
> Wirkung.

Versuche mal:

http://www.dslreports.com/drtcp

Mit drtcp.exe einstellen:
Tcp Receive Window: 511104, Window Scaling: Yes, Time Stamping: No,
Selective Acks: Yes, Path MTU Discovery: Yes, Black Hole Detection: Yes, TTL
64, MTU (am passenden Adapter) 1492, Save, Neustart.

--
Gruß
Ralf
Ich mag kein TOFU. Siehe http://einklich.net/usenet/zitier.htm
Bei Direkt-Mails NOSPAM entfernen

Hallo Ralf,


> Mit drtcp.exe einstellen:
> .....
Keine Veränderung. Ich habe auch mit Window Size 1GB versucht, keine Wirkung.

Die Liste unten zeigt das Verhalten:

35772 251.772559: Send, 126237
35773 251.772888: Send, 126977
35774 251.855437: Ack, winSize = 126977 - 124827 = 2150 Bytes, AckDelay =
000.086212
35776 251.985246: Ack, winSize = 126977 - 126977 = 0 Bytes, AckDelay =
000.212358
35780 251.990230: Send, 128387
35781 251.990562: Send, 129797
35782 252.085430: Ack, winSize = 129797 - 129797 = 0 Bytes, AckDelay =
000.094868
35786 252.090421: Send, 131207
35787 252.090425: Send, 132617
35788 252.195598: Ack, winSize = 132617 - 132617 = 0 Bytes, AckDelay =
000.105173
35793 252.202253: Send, 134027
35794 252.202258: Send, 135437
35795 252.202261: Send, 136847
35796 252.295448: Ack, winSize = 136847 - 134027 = 2820 Bytes, AckDelay =
000.093195
35799 252.298767: Send, 138257
35800 252.315414: Ack, winSize = 138257 - 136847 = 1410 Bytes, AckDelay =
000.113153
35804 252.320735: Send, 139667
35805 252.320738: Send, 141077
35806 252.385314: Ack, winSize = 141077 - 138257 = 2820 Bytes, AckDelay =
000.086547
35810 252.389967: Send, 142487
35811 252.389970: Send, 143361
35812 252.435237: Ack, winSize = 143361 - 141077 = 2284 Bytes, AckDelay =
000.114499
35816 252.440222: Send, 144771
35817 252.440554: Send, 146181
35818 252.495481: Ack, winSize = 146181 - 142487 = 3694 Bytes, AckDelay =
000.105514
35821 252.498801: Send, 147457
35822 252.525434: Ack, winSize = 147457 - 144771 = 2686 Bytes, AckDelay =
000.085212
35826 252.530420: Send, 148867
35827 252.530752: Send, 150277
35828 252.555387: Ack, winSize = 150277 - 146181 = 4096 Bytes, AckDelay =
000.114833
35831 252.558377: Send, 151553
35832 252.635605: Ack, winSize = 151553 - 148867 = 2686 Bytes, AckDelay =
000.105185
35837 252.641920: Send, 152963
35838 252.642252: Send, 154373
35839 252.642255: Send, 155649
35840 252.855274: Ack, winSize = 155649 - 150277 = 5372 Bytes, AckDelay =
000.324522
35842 252.865919: Ack, winSize = 155649 - 152963 = 2686 Bytes, AckDelay =
000.223999
35847 252.872576: Send, 157059
35848 252.872581: Send, 158469
35849 252.872584: Send, 159745
35850 252.965443: Ack, winSize = 159745 - 154373 = 5372 Bytes, AckDelay =
000.323191
35852 252.975422: Ack, winSize = 159745 - 154373 = 5372 Bytes, AckDelay =
000.333170
35854 253.105568: Ack, winSize = 159745 - 154373 = 5372 Bytes, AckDelay =
000.463316
35857 253.108895: Send, 159745
35857 253.108895: Retransmission, Next sequence number: 155649
35858 253.195433: Ack, winSize = 159745 - 159745 = 0 Bytes, AckDelay =
000.086538
35862 253.200415: Send, 161155
35863 253.200748: Send, 162565
35864 253.295617: Ack, winSize = 162565 - 162565 = 0 Bytes, AckDelay =
000.094869
35869 253.302267: Send, 163975
35870 253.302270: Send, 165385
35871 253.302273: Send, 166795
35872 253.405786: Ack, winSize = 166795 - 165385 = 1410 Bytes, AckDelay =
000.103516
35876 253.410778: Send, 168205
35877 253.410781: Send, 169615
35878 253.495650: Ack, winSize = 169615 - 165385 = 4230 Bytes, AckDelay =
000.193380
35881 253.498637: Send, 171025

Die Frames 35793, 35794 und 35795 werden schnell hintereinander gesendet.
TCP wartet dann 93ms auf Acknowledge. Das Window ist zur dieser Zeit nur mit
2820 + 1410 Bytes (die Liste zeigt 1 Frame zu wenig) gefüllt.

Ich habe mit Dream FTP Server, Fastream IQ Web FTP Server, Quick 'n Easy FTP
Server, Sysax FTP und ServU FTP server - immer das gleiche Verhalten. Mit
ServU kann ich 8 Sessions parallel starten und erreiche dann in Summe 1Mbit/s
- mit XP-FTP server kann man nur 2 Sessions starten.

Das gleiche tcp-Verhalten ist auch beim Kopieren mit Explorer und mit
Windows Media Player.

Grsse, Mats

Mats <Mats@discussions.microsoft.com> schrieb:

> Das gleiche tcp-Verhalten ist auch beim Kopieren mit Explorer und mit
> Windows Media Player.

Also hat das nichts mit ftp zu tun. Und natürlich ist das nicht normal.
Was da nun kaputt ist, kann ich Dir nicht sagen.
Du solltest mal alle Deine Registry-Änderungen wieder auf Standard setzen
und allenfalls DRTCP wie beschrieben einsetzen. Achja, bevor Du fragst:

drtcp setzt folgende Werte:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters
TcpWindowSize = 0x7cc80 (511104)
Tcp1323Opts = 1
SackOpts = 1
EnablePMTUDiscovery = 1
EnablePMTUBHDetect = 0
DefaultTTL = 0x40 (64)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\NdisWan\Parameters\Protocols\1
(create key)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\Interfaces\{lange
Nummer}
MTU = 0x5d4 (1492)

Alle diese Werte löschen heißt Standard wiederherstellen.

Falls Du über Deine sonstigen Änderungen nicht "Buch geführt" hast, bleibt
wohl nur eine Neuinstallation.

--
Gruß
Ralf
Ich mag kein TOFU. Siehe http://einklich.net/usenet/zitier.htm
Bei Direkt-Mails NOSPAM entfernen

Ralf Breuer <rhbreuerNOSPAM@t-online.de> schrieb:

> bleibt wohl nur eine Neuinstallation.

Vorher noch versuchen:

http://support.microsoft.com/kb/299357

Start, ausführen, cmd
netsh int ip reset ipreset.txt

Vorsicht, ipreset löscht feste IPs.


http://support.microsoft.com/kb/326155
netsh winsock reset

Ingrid ;-)

Hallo Ralf,

> Also hat das nichts mit ftp zu tun. Und natürlich ist das nicht normal.
Ja, meine Hypothese war falsch.

> Falls Du über Deine sonstigen Änderungen nicht "Buch geführt" hast, bleibt
Ich habe mit 3 frisch installierte Rechner angefangen - immer das gleiche
Verhalten.

Mein Eindruck ist, dass tcp aus dem slow start nie hinauskommt.
Normalerweise schickt TCP am Anfang einige Pakete und wartet auf Acknowledge
und erhöht dann langsam die Geschwindigkeit. In diesem Fall bleibt der TCP in
der Slow Start Modus. Es gibt einige Paketverluste shon am Anfang
(retransmissions). Das Verursacht vielleicht das Problem. Mit einem Unix FTP
Server sehe ich das Problem nicht.

Die Strategie von TCP ist ja für Wireless nicht optimal, siehe z.B.
http://www.cis.temple.edu/~latecki/C...ortLayer-2.ppt
Man kann erkennen, dass bei einem Paketverlust die Ãœbertragung kurz stoppt
aber dann wieder anfängt.

Ich werde das Problem weiter untersuchen.

Grüsse, Mats

Mats <Mats@discussions.microsoft.com> schrieb:

> Es gibt einige Paketverluste shon am Anfang (retransmissions).
> Das Verursacht vielleicht das Problem.

Ziemlich sicher.

Wie wäre es denn mit Kabel? ;-)

--
Gruß
Ralf
Ich mag kein TOFU. Siehe http://einklich.net/usenet/zitier.htm
Bei Direkt-Mails NOSPAM entfernen

Hallo,

wie soll man das verstehen?

"Microsoft TechNet

http://technet2.microsoft.com/window....mspx?mfr=true

TcpWindowSize

"The stack also tunes itself based on the media speed:
- Below 1 Mbps: 8 KB
- 1 Mbps 100 Mbps: 17 KB
- Greater than 100 Mbps: 64 KB"

- Wie kann tcp media speed erkennen?
- Was wird getunt?
- Ist das in RFC 793 festgelgt oder ist das eine Windows spezifische
Implementierung? Bei einem Unix Rechner habe ich das nicht beobachtet.
- Mit 200ms Delay und 1Mbps Bandbreite ist die maximale
Ãœbertragungsgeschwindigkeit 8Kb * 8 bit / 200ms = 320 Kbps, d.h. man kann die
1Mbps nicht ausnutzen?


Bemerkungswert ist auch:

http://technet2.microsoft.com/window....mspx?mfr=true

"SynAttackProtect
Mgliche Auswirkung
....können die auf jedem Adapter konfigurierten skalierbaren Fenster und
TCP-Parameter (einschlielich der Socketoptionen fr die anfngliche RTT-Zeit
(Initial Round Trip Time) und der Fenstergre) nicht mehr ausgeführt werden. "

Grüsse, Mats

Mats <Mats@discussions.microsoft.com> schrieb:

> wie soll man das verstehen?

Garnicht. Ich verstehe Dich nicht. Warum bringst Du nicht Deine
Netzwerk-Ausstattung in Ordnung, sondern versuchst, durch drehen an vielen
Parametern zu erreichen, was in Deiner Umgebung anscheinend nicht möglich
ist?

> - Wie kann tcp media speed erkennen?

Schau in den Status Deiner Netzwerkverbindung.

> - Was wird getunt?

Schau Dir lieber mal die Fensterskalierung an:
http://support.microsoft.com/kb/224829

> - Mit 200ms Delay und 1Mbps Bandbreite ist die maximale
> Übertragungsgeschwindigkeit 8Kb * 8 bit / 200ms = 320 Kbps, d.h. man
> kann die 1Mbps nicht ausnutzen?

Achwas. Es wird nicht jedes Paket beantwortet.

Und nochmal: Du hast kein XP-Problem, sondern ein Problem mit Deiner
Hardware-Ausstattung.

Noch eine Info: Alle die Parameter, an denen Du drehst, sind bei Vista und
folgenden heiße Luft. Der ganze TCP/IP-Kram ist vollständig neu
programmiert.

--
Gruß
Ralf
Ich mag kein TOFU. Siehe http://einklich.net/usenet/zitier.htm
Bei Direkt-Mails NOSPAM entfernen

Hallo Ralf,

> > - Wie kann tcp media speed erkennen?
> Schau in den Status Deiner Netzwerkverbindung.

Ich kann es leicht erkennen aber die Frage war, wie kann der tcp Stack
automatisch die Geschwindigkeit erkennen. Ich befürchte, dass Windows tcp aus
der Verzögerung die Geschwindigkeit abschätzt - war falsch wäre. Meine
Beobachtungen stimmen mit dem Artikel überein aber ist Windows XP tcp stack
so schlecht? 1Mbps steht zur Verfügung aber die theoretische obere Grenze ist
nur 33% davon!


> Und nochmal: Du hast kein XP-Problem, sondern ein Problem mit Deiner
> Hardware-Ausstattung.

Das ist doch keine Basis für eine Diskussion. Die Anforederung ist, eine
1Mbps Wireless-Verbindung zu testen. Die Fragestellung ist, ob Windows XP
professional für eine solche Aufgabe geeignet ist.

Es ist erstaunlich, dass es keine ordentliche beschreibung gibt, wie der TCP
Implementierung sich verhält. Wenn ich etwas Bei Microsoft gefunden habe,
weiss ich nie, wann es geschrieben wurde und auf welcher Stack Version die
Aussagen zutreffen.

> Schau Dir lieber mal die Fensterskalierung an:
> http://support.microsoft.com/kb/224829
KB224829 nicht auf WinXP. Darin kann man z.B. lesen "Windows scaling, For
more efficient use of high bandwidth networks, ...... scaling factor is used.
" aber window scaling ist für Netzwerke mit grossen Verzögerungen eingeführt
worden - nicht High Bandwidth.

Die Diskussion führt nicht weiter. Ich werde nur etwas posten, wenn ich eine
Lösung gefunden habe. Es sieht aber so aus, dass Windows XP als Server nicht
geeignet ist. Leider gibt es auch keine Information darüber, ob Windows
Server, Vista etc. besser ist.