RWIN bei Windows 7 64Bit läßt sich nicht höher wie 65535 einstellen: Wie kann man die Fensterskalierung höher einstellen?
#1
geschrieben 18. September 2017 - 23:25
Unter Windows XP 32 Bit Pro machte man das so:
MTU=1492, TTL=64, RWIN=1045440 bei (DSL 50MBit/s)
Wenn man nun aber Windows 7 vergleicht, bleibt der RWIN bei 65340 (unter 65535) und ist es egal, wie man die RWIN Werte einträgt und auch die Automatik abschaltet unter CMD Administrator " netsh int tcp set global autotuninglevel=disabled ".
Der RWIN Wert geht nicht höher.
Gibt es einen Trick, wie man die Fensterskalierung höher einstellen kann?
Link zum testen der Netzwerkverbindung:
https://www.speedgui...et/analyzer.php
Als Beispiel hier Windows XP 32 Bit Pro:
Windows 7 64 Bit Ultimate:
Hier mal die Registry Werte:
Windows Registry Editor Version 5.00
;DSL Werte festsetzen
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\Parameters]
"DefaultReceiveWindow"=dword:000ff3c0
"DefaultSendWindow"=dword:0003fcf0
"IgnorePushBitOnReceive"=dword:00000000
;DSL Cache Werte einstellen
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]
"AdapterTimeoutCacheTime"=dword:00000078
"CacheHashTableBucketSize"=dword:00000180
"CacheHashTableSize"=dword:0000fa00
"NegativeSOACacheTime"=dword:00000000
"MaxNegativeCacheTtl"=dword:00000000
"MaxSOACacheEntryTtlLimit"=dword:0000012d
"MaxCacheTtl"=dword:00002a30
"NetFailureCacheTime"=dword:00000000
"MaxCacheEntryTtlLimit"=dword:0000012d
;DSL Werte einstellen
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"SackOpts"=dword:00000001
"Tcp1323Opts"=dword:00000001
"TcpMaxDataRetransmissions"=dword:00000007
"TcpMaxDupAcks"=dword:00000002
"TcpNumConnections"=dword:00fffffe
"MTU"=dword:000005D4
"DefaultTTL"=dword:00000040
"TcpWindowSize"=dword:000ff3c0
"GlobalMaxTcpWindowSize"=dword:000ff3c0
"KeepAlive"=dword:00927c00
"DefaultReceiveWindow"=dword:000ff3c0
"DefaultSendWindow"=dword:0003fcf0
"DisableTaskOffload"=dword:00000001
"IPAutoconfigurationEnabled"=dword:00000000
;DSL max. Verbindungen
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000032
"MaxConnectionsPer1_0Server"=dword:00000032
;QoS (Bandbreiten-Reservierung) deaktivieren:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Psched]
"NonBestEffortLimit"=dword:00000000
;Priorität einstellen
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\ServiceProvider]
"Class"=dword:00000008
"DnsPriority"=dword:00000006
"HostsPriority"=dword:00000005
"LocalPriority"=dword:00000004
"NetbtPriority"=dword:00000007
Anzeige
#2
geschrieben 19. September 2017 - 06:41
Zitat
https://de.wikipedia..._Receive_Window
#3
geschrieben 20. September 2017 - 09:37
Bei Windows XP ließ sich die Fenstergröße noch skalieren.
Dann liegt das an den neueren Treibern.
Hatte mich schon gewundert, warum sich RWIN nicht höher einstellen ließ.
Gut zu wissen, danke
#4
geschrieben 20. September 2017 - 13:47
In Windows 7, unless "TCP/IP Auto-Tuning" is disabled, only the Current TCP Window is displayed.
Solange das Auto-Tuning aktiviert ist, regelt Windows die meisten TCP Parameter. Manuelle Eintragungen werden da ignoriert.
Musst vorher in einer Konsole mit Adminrechten eingeben:
netsh int tcp set heuristics disabled
netsh int tcp set global autotuninglevel=disabled
Dann sollten manuelle Änderungen wieder greifen.
RWIN Scaling funktioniert nach wie vor mit Windows 7/10.
---
Musst allerdings auch aufpassen, welchen Browser Du für die Seite da oben verwendest. Chrome und IE 11 zeigen da unterschiedliche Werte an:
Chrome:
Default TCP Receive Window (RWIN) = 66560
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 260
IE 11:
Default TCP Receive Window (RWIN) = 262144
RWIN Scaling (RFC1323) = 3 bits (scale factor: 2^3=8)
Unscaled TCP Receive Window = 32768
Welcher Wert da nun der Richtige ist, bin ich gerade auch überfragt. Allerdings ist es bekannt, das Chrome am TCP Windows selber währen der Sitzung rumschraubt, so dass die Werte aus Chrome nicht unbedingt die globalem Windows Werte darstellen.
Edge unter Windows 10 kann ich da gerade nicht testen, da dieser irgendwie rum spinnt.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#5
geschrieben 21. September 2017 - 22:46
Also:
Ich habe die beiden Befehle unter CMD Admin ausprobiert, leider geht der RWIN unter 65535.
Bei XP ging das ohne Probleme.
Die Paketgröße ist zwar richtig, aber die Skalierung arbeitet nicht.
Ich frage mich schon die ganze Zeit, was die Ursache ist.
RWIN Werte sind eingetragen, MTU läßt sich ändern, TTL auch, aber diese Skalierung will nicht höher.
Ich habe sogar mal den SG TCP Optimizer 2.0.3 und den neueren 4.0.6 ausprobiert.
Werte sind korrekt eingetragen, aber die Skalierung will einfach nicht?!
Müsste ich vielleicht noch etwas mit " netsh " unter cmd Admin abstellen?
Hier mal die Einstellung im SG TCP Optimizer 4.0.6:
Dieser Beitrag wurde von Phoenix0870 bearbeitet: 21. September 2017 - 23:13
#6
geschrieben 22. September 2017 - 06:38
Dieser Beitrag wurde von Gispelmob bearbeitet: 22. September 2017 - 06:55
#7
geschrieben 22. September 2017 - 10:03
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters]
"Tcp1323Opts"=dword:00000001
"TcpWindowSize"=dword:000ff3c0
"GlobalMaxTcpWindowSize"=dword:000ff3c0
"DefaultReceiveWindow"=dword:000ff3c0
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AFD\ Parameters]
"DefaultReceiveWindow"=dword:000ff3c0
Dann hatte auch die Skalierung (Scaling) gegriffen.
Nun ist der RWIN Wert ein Multiplikator?
Ist das richtig?
Wie mache ich das nun in Windows 7, grübel...
Dieser Beitrag wurde von Phoenix0870 bearbeitet: 22. September 2017 - 10:09
#8
geschrieben 22. September 2017 - 11:13
Beim Windows 7 in der VM sieht das so aus, wenn ich die Automatik walten lasse:
RWIN Scaling steht automatisch auf 8.
Was die Registry Werte angeht, so muss ich erst einmal suchen, wo die sich befinden.
Was ich bis jetzt so gelesen habe:
TcpWindowSize und MTU befindet sich jetzt unter
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\ interface-name
Ob man die noch global setzen kann, kann ich gerade nicht ermitteln.
GlobalMaxTcpWindowSize und Tcp1323Opts befindet sich nach wie vor unter
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Wie gesagt, schon lange nicht mehr mit beschäftigt. Lasse da alles auf Automatik laufen und gut. Bin da momentan auch etwas am überlegen. Nicht alles, was mit XP ging, geht auch mit Vista bzw. 7 und neuer.
Auch bin ich mir nicht so sicher, wie zuverlässig die Seite da oben wirklich noch ist. Die Seite gibt einen MTU=1492 an, netsh zeigt aber MTU=1500 an für den einzigen Adapter an. Das letze Mal, als ich auf der Seite war, hatte ich noch ein reines DSL Modem, welcher direkt am Rechner hing. Jetzt hängt ja ein Router dran und ich sehe das Modem ja gar nicht mehr.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#9
geschrieben 22. September 2017 - 22:10
Wie ist das denn möglich, den RWIN auf Faktor 8 einzustellen?
Durch die Automatik?
Denke, das es schon Stellschrauben gibt, wo man direkt den RWIN festsetzen kann, bloß wo?
Bin hier am rätseln, wie ich überhaupt den RWIN erhöhen kann, wenn RWIN ein Multiplikator von MSS ist.
Welcher Registryeintrag ist das denn?
Bei mir will der nicht höher, auch wenn die normalen RWIN Größe ok.
Ist zwar nicht skaliert, aber die Verbindung arbeitet soweit gut.
Die Automatik will etwas über 66048 setzen, was total die Verbindung lahm macht.
Du hast einen Router dran, aber MTU 1492, statt 1500?
Könnte am Header liegen, der ja auch 8 Byte in Anspruch nimmt.
Selbst der neue SG TCP Optmizer 4.0.6 kann nicht den RWIN skalieren.
Die Automatik haut bei mir garnicht hin, alles lahmt, egal auf welcher Seite ich bin.
Mein Router ist ein Hitron von ehemals Kabel-Deutschland, jetzt Vodafone.
Dort kann ich leider nicht einstellen.
Auch habe ich CfosSpeed mal ausprobiert, selbst der bekommt den RWIN nicht höher.
Selbst die Datei tcpip.sys auf c:\windows\system32\drivers habe ich mal ausgetauscht, was aber leider auch nicht ging, da es zu keiner Netzwerkverbindung kommt.
Vielleicht gibt es Patch, der das beheben könnte?!
Dieser Beitrag wurde von Phoenix0870 bearbeitet: 22. September 2017 - 22:31
#10
geschrieben 22. September 2017 - 23:14
Netzwerke heutzutage sind doch leistungsfähig genug. So leistungsfähig, daß potentiell eher das Speichersystem an einem der Enden einen Flaschenhals bildet - 125MB/s müssen auch erstmal weggeschrieben werden, ggf kontinuierlich; und mit 10GbE überfordert man auch SSDs.
Wenn was mit der Performance nicht hinhaut, müßte man schauen, woran es hängt. Die TCP-Optionen sind es vermutlich nicht.
#11
geschrieben 23. September 2017 - 00:00
Auch im anderen Forum ist das anscheinend ein Problem:
https://www.ip-phone...%A4ndern.78594/
Die Automatik läßt den RWIN größer werden, aber nicht optimal.
Seiten brauchen um einiges länger, bis sie komplett dargestellt werden.
Zu den SSD, ich habe 2 verbaut, eine für Windows und eine um auszulagern.
Das ist aber nicht das Problem, sondern RWIN Scaling zu aktivieren, was es bei Win 7 nicht mehr macht.
Habe eben noch dieses hier gelesen:
" Bei einem RWin von 64K-1 und den Standardeinstellungen von Windows (Timestamps (RFC1323) = OFF...) sowie den TCP-Options sieht's stark danach aus, daß auch Window Scaling deaktiviert ist, ohne das du nie über 64K-1 hinwegkommst.
->
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\ Parameters]
"EnablePMTUBHDetect"=dword:1
"Tcp1323Opts"=dword:3
Leider bringt das auch nichts.
Dieser Beitrag wurde von Phoenix0870 bearbeitet: 23. September 2017 - 01:17
#12
geschrieben 23. September 2017 - 07:34
Zitat
Dieser Beitrag wurde von Gispelmob bearbeitet: 23. September 2017 - 07:56
#13
geschrieben 23. September 2017 - 07:58
Zitat
Um größere Fenstergrößen zu erhalten, die Hochgeschwindigkeits-Übertragungswege aufnehmen können, definiert RFC 1323 (ietf.org/rfc/rfc1323.txt) eine Fensterskalierung, die ermöglicht, dass ein Empfänger eine Fenstergröße von mehr als 65.535 Byte mitteilt. Eine TCP-Fensterskalierungsoption umfasst einen Fensterskalierungsfaktor, der in Kombination mit dem 16-Bit-Fensterfeld im TCP-Header die Empfangsfenstergröße auf einen Maximalwert von ca. 1 GB vergrößern kann. Die Fensterskalierungsoption wird während der Verbindungsherstellung nur in SYN-Segmenten gesendet. Beide TCP-Peers können unterschiedliche Fensterskalierungsfaktoren für ihre Empfangsfenstergrößen angeben. Indem einem Sender ermöglicht wird, mehr Daten über eine Verbindung zu senden, ermöglicht die TCP-Fensterskalierung die bessere Nutzung einiger Typen von Übertragungswegen mit hohen BDPs durch die TCP-Knoten.
---
Ich bin ein kleiner, schnickeldischnuckeliger Tiger aus dem Schwarzwald.
Alle haben mich ganz dolle lila lieb.
#14
geschrieben 23. September 2017 - 08:33
Zitat
Im Original
Zitat
Zitat
Dieser Beitrag wurde von Gispelmob bearbeitet: 23. September 2017 - 08:37
#15
geschrieben 23. September 2017 - 08:52
Dann frage ich mich, warum XP das immer machte?
Testlink um abzulesen:
https://www.speedgui...et/analyzer.php
Ergebnis:
Timestamps (RFC1323) = OFF
Die Option TCP Option 1323 = 1 reagiert bei Windows 7 nicht, bei XP ja.
Selbst wenn ich die Option = 3 setze, übernimmt Win7 das nicht.
Ist aber die Automatik an (netsh int tcp set global autotuninglevel=normal), dann geht der RWIN auf 66048.
Ich brauche nicht mal neuzustarten, es reagiert sofort.
Wenn es in der Automatik möglich ist, müsste es auch manuell höher einzustellen zu gehen.
Bloß diesen Wert 66048 fand ich in der Registry nicht.
Und gebe ich unter CMD netsh int tcp set global timestamps=enabled ein, sieht es so aus:
Default TCP Receive Window (RWIN) = 65536
RWIN Scaling (RFC1323) = 8 bits (scale factor: 2^8=256)
Unscaled TCP Receive Window = 256
Timestamps (RFC1323) = ON
Note: Timestamps add 12 bytes to the TCP header of each packet, reducing the space available for useful data.
Das würde den Wert 3 entsprechen, aber wie stelle ich den per netsh auf 1 ein?
Mache ich nun folgendes:
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global timestamps=enabled
So geht der RwIN wieder unter 64K und Timestamps ist off.
Seltsam...
Nächster Test ohne Neustart:
netsh int tcp set global autotuninglevel=restricted
netsh int tcp set global timestamps=enabled
Default TCP Receive Window (RWIN) = 65600
RWIN Scaling (RFC1323) = 4 bits (scale factor: 2^4=16)
Unscaled TCP Receive Window = 4100
Timestamps (RFC1323) = ON
Test1 ohne Neustart:
netsh int tcp set global autotuninglevel=highlyrestricted
netsh int tcp set global timestamps=enabled
Default TCP Receive Window (RWIN) = 66176
RWIN Scaling (RFC1323) = 2 bits (scale factor: 2^2=4)
Unscaled TCP Receive Window = 16544
Timestamps (RFC1323) = OFF
Hier wird Timestamps off geschaltet, obwohl ich angeschaltet habe.
Test2 ohne Neustart:
netsh int tcp set global autotuninglevel=experimental
netsh int tcp set global timestamps=enabled
Default TCP Receive Window (RWIN) = 65536
RWIN Scaling (RFC1323) = 14 bits (scale factor: 2^14=16384)
Unscaled TCP Receive Window = 4
Timestamps (RFC1323) = ON
Das beste Ergebnis ist:
netsh int tcp set global autotuninglevel=disabled
netsh int tcp set global timestamps=disabled
Wenn auch ohne Skalierung, aber der Seitenaufbau ist flüssig.
Finde das schon seltsam, das Timestamps dann immer auf OFF geht, selbst wenn man es per netsh auf ON stellt?!
netsh int tcp set global autotuninglevel=disabled sperrt alle Einstellungen außer MTU und TTL.
RWIN Scaling wird deaktiviert, egal ob man nun GlobalTcp1323=3 oder DefaultTcp1323=3 in Registry einträgt.
MS hätte dort netsh int tcp set global autotuninglevel=manual einführen müssen, damit der Anwender seine Werte selbst einstellen kann.
Ohne Patch der tcpip.sys wird das wohl nie möglich sein, schade.
So habe mal eben MS anschrieben wegen Hotfix.
Hotfix improves TCP window scaling in Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2
https://support.micr...ndows-server-20
Vielleicht klärt das die Sache allgemein und man kann doch etwas verändern?
Dieser Beitrag wurde von Phoenix0870 bearbeitet: 23. September 2017 - 10:49