jlebris 10 Geschrieben 2. Juni 2008 Melden Teilen Geschrieben 2. Juni 2008 Hallo, hoffe mal das hier jemand schon Erfahrung hat. Verbindung: 1) Client (XP SP2) und Server (2003 SP1) über WAN Latency ca. 20 ms 2) Client (XP SP2) und Client (XP SP2) über cross over Kabel HP Netzwerkarten auf Clients und Server! Probelm: Druch die Latency veringert sich die Performance des Datendurchsatzes. Versuchte Lösung: Testweise erhöhung folgende 2 Parameter: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters DWORD TcpWindowSize 524280 = decimal HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters DWORD Tcp1323Opts 3 = decimal Testbericht: Keine Veränderung der Performance sowohl von Client zu Server als auch von Client zu Client. Ich habe das ganze mal mit protokoliert und mir ist vorallem aufgefallen, dass trozt des setzens der Parameter in der Registry kein scaling (siehe Window: 65535 (scale factor not found) durchgeführt wir. Kann mir das jemand erklären oder mir ein Hinweis senden wo der Hund begraben sein könnte? Anbei das Log: Frame: - Ethernet: Etype = Internet IP (IPv4) - DestinationAddress: Compaq Computer Corporation E958FE IG: (0.......) Individual address UL: (.0......) Universally Administered Address Rsv: (..000000) - SourceAddress: Hewlett Packard 3C1358 UL: .0...... Universally Administered Address EthernetType: Internet IP (IPv4), 2048(0x800) UnkownData: Binary Large Object (6 Bytes) - Ipv4: Next Protocol = TCP, Packet ID = 20699, Total IP Length = 40 - Versions: IPv4, Internet Protocol; Header Length = 20 Version: (0100....) IPv4, Internet Protocol HeaderLength: (....0101) 20 bytes (0x5) - DifferentiatedServicesField: DSCP: 0, ECN: 0 DSCP: (000000..) Differentiated services codepoint 0 ECT: (......0.) ECN-Capable Transport not set CE: (.......0) ECN-CE not set TotalLength: 40 (0x28) Identification: 20699 (0x50DB) - FragmentFlags: 16384 (0x4000) Reserved: (0...............) DF: (.1..............) Do not fragment MF: (..0.............) This is the last fragment Offset: (...0000000000000) 0 TimeToLive: 128 (0x80) NextProtocol: TCP, 6(0x6) Checksum: 20419 (0x4FC3) SourceAddress: 172.23.1.1 DestinationAddress: 172.23.1.2 - Tcp: Flags=....A..., SrcPort=Microsoft-DS(445), DstPort=1106, Len=0, Seq=1531078484, Ack=671147358, Win=65535 (scale factor not found) SrcPort: Microsoft-DS(445) DstPort: 1106 SequenceNumber: 1531078484 (0x5B426754) AcknowledgementNumber: 671147358 (0x2800E55E) - DataOffset: 80 (0x50) DataOffset: (0101....) (20 bytes) Reserved: (....000.) NS: (.......0) Nonce Sum not significant - Flags: ....A... CWR: (0.......) CWR not significant ECE: (.0......) ECN-Echo not significant Urgent: (..0.....) Not Urgent Data Ack: (...1....) Acknowledgement field significant Push: (....0...) No Push Function Reset: (.....0..) No Reset Syn: (......0.) Not Synchronize sequence numbers Fin: (.......0) Not End of data Window: 65535 (scale factor not found) Checksum: 32670 (0x7F9E) UrgentPointer: 0 (0x0) LG Jerome Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 2. Juni 2008 Melden Teilen Geschrieben 2. Juni 2008 Hm so schlecht ist die Latenz mit 20ms garnicht.... ohne deinen Trace genau gelesen zu haben würde ich mal mit den Treiber experimentieren, sprich auf den neusten Stand bringen. Druch die Latency veringert sich die Performance des Datendurchsatzes. Kannst du das quantifizieren? Was geht denn wirklich durch die Leitung? Wie misst du das? Weisst ja, wer misst misst Mist... Zitieren Link zu diesem Kommentar
jlebris 10 Geschrieben 3. Juni 2008 Autor Melden Teilen Geschrieben 3. Juni 2008 Danke Sammy Die Latenz ist mit 20 ms über WAN tatsächlich nicht schlecht aber darum geht es mir auch gar nicht. Mit 20 ms hat man durch den Aufbau von TCP/IP jedoch automatisch eine veringerte Bandbreitenausnützung. Beispiel: True Flow Control Windows Size 70080 Bytes (das konnte ich ja mitschniffen Window: 65535 (scale factor not found) bei 1ms max Durchsatz 560 Mbps bei 5ms max Durchsatz 112 Mbps bei 10ms max Durchsatz 56 Mbps bei 20ms max Durchsatz 28 Mbps Das ganze ist auch durch eine Auswertung durch einen Netzwerksniffer "IT Guru" mit einer Analyse bestätigt worden. Mein Problem ist, das Windows XP und Windows 2003 die Windows Size bis 65535 automatisch erweitert bei Bedarf.Windows TCP/IP unterstütz jedoch Scaling womit ich den Windows Size erweitern kann bis zu einem Faktor X um den Durchsatz der mir durch die Latency verloren geht wieder zu kompensieren. Genau das funktioniert bei mir leider nicht habe mir bereits die Netzwerktreiber angeschaut aber nicht wirklich ein Problem festgestellt. Falls noch jemand eine Idee hat einfach her damit :-) Was muss gegeben sein das windows ein scaling betreibt? Vielleicht gibts ja hier jemand der das bewußt einsetzt. (Mit Google gibts da wirklich wenig) Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 3. Juni 2008 Melden Teilen Geschrieben 3. Juni 2008 Mit 20 ms hat man durch den Aufbau von TCP/IP jedoch automatisch eine veringerte Bandbreitenausnützung. Beispiel: True Flow Control Windows Size 70080 Bytes (das konnte ich ja mitschniffen Window: 65535 (scale factor not found) bei 1ms max Durchsatz 560 Mbps bei 5ms max Durchsatz 112 Mbps bei 10ms max Durchsatz 56 Mbps bei 20ms max Durchsatz 28 Mbps das musst du mir erklaeren...vor allem wie du auf die Werte kommst... Mein Problem ist, das Windows XP und Windows 2003 die Windows Size bis 65535 automatisch erweitert bei Bedarf.Windows TCP/IP unterstütz jedoch Scaling womit ich den Windows Size erweitern kann bis zu einem Faktor X um den Durchsatz der mir durch die Latency verloren geht wieder zu kompensieren. Die Window Size wird von der eigentlichen Applikation bestimmt und gibt die groesse des Empfangspuffers an... ich weiss nicht genau was du mit scaling meinst. Meinst du vielleicht congestion control? Zitieren Link zu diesem Kommentar
jlebris 10 Geschrieben 4. Juni 2008 Autor Melden Teilen Geschrieben 4. Juni 2008 Das PDF das ich hier habe ist zu groß. Aber folgende links erklären in etwa was ich machen möchte: (Fensterskalierung) Description of Windows 2000 and Windows Server 2003 TCP Features (am Ende des artikels gibt es zusätzlich noch ein Download link für TCP/IP bei Windows) Enabling High Performance Data Transfers [PSC] LG Jerome Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 4. Juni 2008 Melden Teilen Geschrieben 4. Juni 2008 Hm interessant... mit den TCP Options hatte ich mich noch nie beschäftigt. Wenn ich das bei meiner WinXP und W2K3 Kiste setze scheinen die TCP Options gesetzt zu werden. Sprich DWORD Tcp1323Opts 3 = decimal und die Window Size habe ich gelassen wie sie war... Mir ist noch nicht klar, wo ich den eigentlichen Skailierungsfaktor setzen kann... Hab das noch gefunden vielleicht hilfts ja... TCP Receive Window Size and Window Scaling Werd morgen weiterexperimentieren... Zitieren Link zu diesem Kommentar
Squire 214 Geschrieben 4. Juni 2008 Melden Teilen Geschrieben 4. Juni 2008 Frage - was heißt Wan bzw. wie schnell und welcher Art ist Dein WAN? Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 5. Juni 2008 Melden Teilen Geschrieben 5. Juni 2008 Also, bei mir hat das wunderbar funktioniert...habe für die WindowSize ein Vielfaches der MSS (1460 Byte) genommen, also: 44 x 1460 = 64240 x 2^2 = 256960 Client: TcpWindowSize Dword dezimal = 256960 Tcp1323Opts Dword dezimal = 3 Server: TcpWindowSize Dword dezimal = 256960 Tcp1323Opts Dword dezimal = 3 GlobalMaxTcpWindowSize="256960" hat bei mir keine Wirkung gezeigt... Versuch mal die gleichen Werte wie ich zu verwenden! Zitieren Link zu diesem Kommentar
jlebris 10 Geschrieben 5. Juni 2008 Autor Melden Teilen Geschrieben 5. Juni 2008 @Squire WAN Wide Area Network in diesem Fall ein SDH Ring mit 100 MBits und einer Latency auf der Strecke mit ca. 20ms. @Sammy Vielen Dank ich komme der Sache deutlich näher. Man(n) sieht wieder 4 Augen sind besser als 2. Ich habe das ganze auch mal mit Deinen Werten nachgestellt. 44 x 1460 = 64240 x 2^2 = 256960 Client: TcpWindowSize Dword dezimal = 256960 Tcp1323Opts Dword dezimal = 3 Server: Einträge sind beim Empfänger nicht notwendig laut meinen Tests bei Windows 2003. TcpWindowSize Dword dezimal = 256960 Tcp1323Opts Dword dezimal = 3 Ich habe das ganze mal mit Telnet und FTP überprüft und siehe da scaling wurde gemacht. Danach habe ich mir vom Client ein Server Share gemountet und Daten vom Client auf den Server kopiert. Hier wurde kein scaling gemacht. :-( So wie es für mich aussieht muss auch die dahinter stehende Anwendung dieses scaling unterstützen und da Share mounten und Daten kopieren wohl über NetBios (ohne scaling Unterstützung) läuft funktioniert das ganze für diesen Einsatzzweck nicht! Falls jemand bei einem weiteren Test was anderes Feststellt oder Workaround kennt gerne her damit. Zitieren Link zu diesem Kommentar
sammy2ooo 10 Geschrieben 5. Juni 2008 Melden Teilen Geschrieben 5. Juni 2008 http://www.ietf.org/rfc/rfc1323.txt Abschnitt 2.1 ... The scale factor is carried in a new TCP option, Window Scale. This option is sent only in a SYN segment (a segment with the SYN bit on), hence the window scale is fixed in each direction when a connection is opened. ... und weiter unten ... This option is an offer, not a promise; both sides must send Window Scale options in their SYN segments to enable window scaling in either direction. ... Window Scaling spielt sich nicht auf dem Application Layer ab sondern auf dem Transport Layer und sollte somit unabhängig von NetBIOS sein. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.