Post Reply 
Proxomitron reduces RWIN to 32768
Nov. 10, 2005, 03:03 AM
Post: #72
 
JJoe Wrote:What was done to harden the stack?

HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\Tcpip\ Parameters

SynAttackProtect = 2
TcpMaxHalfOpen = 100
TcpMaxHalfOpenRetired = 400
TcpMaxHalfOpenRetried = 80
TcpMaxPortsExhausted = 5 (possibly should have set this to 0; will look at this later)
TcpMaxConnectResponseRetransmissions = 2
TcpMaxDataRetransmissions = 3

EnablePMTUDiscovery = 1

EnablePMTUDiscovery should really be set to 0 for hardening, and was originally. However a setting of 0 forces the server to send datagrams of 576 bytes. OTOH, when set at 1, it may slow down establishing connections and the initial transfer speed, although it will result in better throughput large packets have to be fragmented somewhere along the line. Have for the moment set it on 1. I'll play with this setting a bit

KeepAliveTime = 300000
NoNameReleaseOnDemand = 1
EnableDeadGWDetect = 0
DisableIPSourceRouting = 2
PerformRouteDiscovery = 0

HKLM\SYSTEM\CurrentControlSet\Services\AFD\Parameters

EnableDynamicBacklog = 10
MaximumDynamicBacklog =20
MinimumDynamicBacklog = 1
DynamicBacklogGrowthDelta = 20000

HKEY_LOCAL_MACHINE \SYSTEM\ CurrentControlSet\Services\Tcpip\ Parameters

EnableDynamicBacklog = 10
MaximumDynamicBacklog = 20
MinimumDynamicBacklog = 1
DynamicBacklogGrowthDelta = 20000

Now out of the above, only the EnablePMTUDiscovery turns up in speed tweaks, when it is set to 1.

Speed Tweaks

Still twiddling with a couple of these.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Interfaces

MTU = 1500

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

TCPWindowSize = 256960

TCPWindow should be a multiple of the Maximum Segment Size (MSS). MSS is generally MTU - 40, where MTU, or Maximum Transmission Unit, is the largest packet size that can be transmitted without fragmentation. MTU is usually 1500 or 1492 for PPPoE connections.

TCP1323Opts = 1
This enables large TCPWindow support, as per RFC 1323. If this parameter is not set to 1, the TCPWindow is limited to 64K. A setting of 1 disables timestamps, which add 12 bytes to the header each packet, thus reducing throughput.

GlobalMaxTcpWindowSize = 256960

If RWIN is chosen as lower than 65535, make it a multiple of MSS and turn scaling off (Tcp1323Opts = 0). Think however that I may need to recalculate this setting.

EnablePMTUBHDetect = 0

Setting this parameter to 1 (True) enables "black hole" routers to be detected, however it also increases the maximum number of retransmissions for a given segment. In most cases this should be kept to 0 (False).

SackOpts = 1

Enables SACK (Selective Acknowledgement) support, as specified in RFC 2018. SACK is particularly important if using large TCP Window sizes.

Still have to add some further tweaks:

DefaultTTL - recommended setting is 64
TcpMaxDupAcks ? recommended setting is 2

But those are for later.

You don't have to set this lot by hand - and in some cases you're having to create keys. Instead you could use Drtcp or TCPOptimizer to do it automatically.

Extra bits

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters]

?NetFailureCacheTime?=dword:00000000
"NegativeSOACacheTime? =dword:00000000
"MaxNegativeCacheTtl"=dword:00000000

And a little registry addition I found and ran:

[HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000020
"MaxConnectionsPer1_0Server"=dword:00000020

HTTP 1.1 specifies that a client can only open up to two simultaneous connections, e.g. one to download text, the other to download images. Anything more than that is queued. OTOH, increasing this value means that the PC can ? if the server allows it - open multiple connections and (for example) download more than one image at a time, thus loading the page faster. It?s worth trying on broadband. On the other hand some servers may enforce the spec to avoid connection hogging, though actually you only hog connections for a much shorter time, leastways on broadband. This one is a bit experimental, and I?ll probably reduce it to somewhere between decimal 4 and 10, which would be a more reasonable value than the one in this registry tweak. It is a bit excessive! :-)

Anyway, that's all the relevant fiddling so far.

JJoe Wrote:
z12 Wrote:I do not see "EventID 4226:" in my logs.

Which should indicate that he is not seeing the problem the patched tcpip.sys is suppose to fix. Yes?

It would do.

JJoe Wrote:See my dilemma?

Yup.

JJoe Wrote:Since you've never had the problem, I must assume that
something else you did solves the problem or maybe the tcpip.sys patch has changed or something most everybody but you does causes it.

Hmm! Well, I just went over to check the speedguide page, and it seems that it gives very different results from dslreports, even with Proxomitron disabled.

Anyway, with speedguide's analyzer (http://www.speedguide.net/analyzer.php) I get an RWIN of 32768 with Proxomitron, with the filters disabled. Dumping the proxy connection in IE6 tools/options gives an RWIN of 257004 (Yup, the latest bit of fiddling put it up). With Proxomitron's filters engaged, I again get a value of 32768.

OTOH, over at http://www.dslreports.com/tweaks I get 257004 with Proxomitron engaged and the filters running.

Interesting. <scratches head!> So - off to speedguide's FAQ on their analyzer:

2. How Does It Work?

The Analyzer reads the information stored in TCP/IP packet headers that are sent from your PC to our server. It does not read your Registry in any way, it simply reads packet headers containing information about your TCP/IP settings. This is the most accurate method we're aware of, since it is OS-independent, and the Analyzer sees what your end actually advertises to external servers (which, in some cases differs from the system configuration).

As the server receives a SYN packet, it extracts the TCP options from it and remembers them, along with the remote port and IP pair. It then continues listening for other packets, which usually arrive (the browser must send at least "GET /" in order to receive any data). Once the browser request is complete, the server sends the simplified web page content, complete with instructions to the Analyzer parser script.

9. I set my RWIN to N, but the Analyzer shows something slightly different. What gives?

While you can enter any RWIN value in the registry, the TCP stack will only accept some values. The value you see on the page is the best compromise between what you entered and what the stack is willing to accept. TCP headers only contain an unscaled RWIN value lower than 65536 and a scale, or rather shift factor used for larger RWINs. Valid RWIN values must be divisible by 2^shift factor. That can create slight differences however the value that the analyzer reads is what every other server on the net will get as well.

14. The Analyzer does not show my MTU value correctly ?

The Analyzer extracts values drectly from packets that your system sends to our server. In other words, the MTU shown is what gets advertised to servers on the Internet.

The most likely cause of different MTU than what you have set for your Registry (using the Optimizer or manually) is that a NAT router on the path is limiting the MTU to a lower value. If you're behind a router, update it to the latest firmware and make sure that its MTU (if user sellectable) is set to the same value. If you are behind a router with recent firmware and no options to change MTU, you can always test whether it's the culprit by removing it and connecting your system to the Internet/Analyzer directly.

Other probable causes are PPPoE software on your system that uses different MTU, or in some rare cases an ISP limiting MTU values. Last, but not least make sure the Analyzer is examining your IP address and not some transparent proxy server.

Whilst under 3 it remarks that:

Note: There are still some routers and cable/dsl modems in use that modify the maximum packet size (regardless of Registry settings). If the Analyzer reports a smaller MTU and you're behind a router, you might want to try updating its firmware, or looking through its management interface for an MTU value.

OK, what to make of this? The maximum packet size isn't being modified by a router or the dsl modem - that's demonstrated by having the higher values when Proxomitron is entirely disconnected from IE6, which is then browsing the net directly. OTOH, the dslreport tester is using an applet. I'm using Sidki's filters, and have to click on "Applet: Tweak 7" to run the test. Perhaps somebody who understands Java might like to have a look and see exactly what it's doing and how.

Upshot is that the two tests are getting the info in different ways, and producing different results. Speedguide acknowledges that downstream items such as routers, dsl modems and proxies may modify the maximum packet size. Now it may be that Proxomitron is doing that, but it only really becomes apparent when you've got a test that's extracting the data directly from the packets, rather than from whatever method dslreports is using.

So I did a bit of rummaging around - whence 32768? I recall, from the dim and distant past, that Proxomitron started off as a program running under Windows 3.1. Perhaps it was a limitation built in from the early days? Found some interesting info, which might suggest that Scott actually maximised the MTU of Proxomitron, based on the RWIN of Unix servers, so that Proxomitron was operating well above anything that contemporary machines on dialup might need. Just a guess:

"Most Unix servers are observed to have an initial RWIN of 32768, suggesting that a cable modem user should have an RWIN of at least 131072, which is actually larger than Windows 95 and Windows NT can manage.

The default RWIN for Windows 9x systems is far too small at 8192, and Win9x systems will thus always display a bad impact on download speeds from uploads. Windows ME is slightly better at 16384, but still not good enough for cable."


http://homepage.ntlworld.com/robin.d.h.w...ownup.html

If that's the case, then it would look as if changes in operating systems, and the takeup of broadband, may have caught up with the MTU set by Scott.

Best I can do - it's nearly 3 am, and I've been having a good slog at this. Brain is about to go on meltdown. :-( Anyone in a position to dissect the program and see what gives? Presumably it was analysed during the development of Proximodo?

Think the bit about tcpip.sys may also be useful - have seen Proxomitron open up a hell of a lot of connections before now. I would guess that if it tried to open up more than 10 at the same time, it would hit this problem. However, on looking at the matter more closely, it may not be the issue here.

Kevin
Add Thank You Quote this message in a reply
Post Reply 


Messages In This Thread
Proxomitron reduces RWIN to 32768 - Tony Tough - Oct. 19, 2005, 06:12 AM
RE: Proxomitron reduces RWIN to 32768 - JJoe - Jan. 10, 2007, 04:09 AM
RE: Proxomitron reduces RWIN to 32768 - Guest - Sep. 28, 2008, 07:17 PM
RE: Proxomitron reduces RWIN to 32768 - Mele20 - Sep. 29, 2008, 12:07 PM
RE: Proxomitron reduces RWIN to 32768 - Kye-U - Sep. 30, 2008, 05:54 PM
RE: Proxomitron reduces RWIN to 32768 - Kye-U - Oct. 09, 2008, 12:22 AM
RE: Proxomitron reduces RWIN to 32768 - Guest - Oct. 14, 2008, 03:16 PM
[] - Kye-U - Oct. 19, 2005, 09:23 PM
[] - elshaddai - Oct. 20, 2005, 12:13 AM
[] - Kye-U - Oct. 20, 2005, 05:00 AM
[] - Guest - Oct. 20, 2005, 06:13 AM
[] - Tony Tough - Oct. 20, 2005, 06:15 AM
[] - Peakaboo - Oct. 20, 2005, 05:27 PM
[] - Kye-U - Oct. 20, 2005, 07:52 PM
[] - Oddysey - Oct. 21, 2005, 07:50 AM
[] - Tony Tough - Oct. 21, 2005, 08:19 AM
Same problem under windows98SE - mambo - Oct. 21, 2005, 08:27 AM
[] - Ralph - Oct. 21, 2005, 12:11 PM
[] - Tony Tough - Oct. 21, 2005, 12:24 PM
[] - Peakaboo - Oct. 21, 2005, 12:39 PM
[] - mambo - Oct. 21, 2005, 12:46 PM
[] - mambo - Oct. 21, 2005, 01:20 PM
[] - Peakaboo - Oct. 21, 2005, 01:40 PM
[] - elshaddai - Oct. 21, 2005, 04:45 PM
Cable Modem - mozerd - Oct. 21, 2005, 05:52 PM
Re: Cable Modem - Peakaboo - Oct. 21, 2005, 06:36 PM
[] - Kye-U - Oct. 21, 2005, 07:43 PM
[] - Kye-U - Oct. 21, 2005, 07:44 PM
Re: Cable Modem - Guest - Oct. 23, 2005, 09:56 PM
Re: Cable Modem - mozerd - Oct. 23, 2005, 11:24 PM
Re: Cable Modem - Guest - Oct. 24, 2005, 02:54 AM
Re: Cable Modem - Tony Tough - Oct. 24, 2005, 05:43 PM
[] - Tony Tough - Oct. 24, 2005, 06:00 PM
[] - hpguru - Oct. 24, 2005, 09:18 PM
[] - Guest - Oct. 24, 2005, 09:35 PM
[] - Guest - Oct. 24, 2005, 09:40 PM
[] - z12 - Oct. 24, 2005, 09:59 PM
[] - Peakaboo - Oct. 24, 2005, 10:24 PM
[] - hpguru - Oct. 24, 2005, 10:30 PM
[] - Guest - Oct. 24, 2005, 10:35 PM
[] - Guest - Oct. 24, 2005, 10:38 PM
[] - Guest - Oct. 25, 2005, 04:11 AM
[] - Guest - Oct. 25, 2005, 04:22 AM
[] - hpguru - Oct. 25, 2005, 07:47 AM
[] - z12 - Oct. 25, 2005, 12:38 PM
[] - ProxRocks - Oct. 25, 2005, 12:38 PM
[] - z12 - Oct. 25, 2005, 01:01 PM
[] - ProxRocks - Oct. 25, 2005, 01:17 PM
[] - Tony Tough - Oct. 25, 2005, 01:21 PM
[] - z12 - Oct. 25, 2005, 01:43 PM
[] - Peakaboo - Oct. 25, 2005, 02:06 PM
[] - hpguru - Oct. 25, 2005, 02:53 PM
[] - JJoe - Oct. 25, 2005, 04:45 PM
[] - mambo - Oct. 25, 2005, 05:09 PM
[] - z12 - Oct. 26, 2005, 01:23 AM
[] - Peakaboo - Oct. 26, 2005, 02:16 AM
[] - z12 - Oct. 26, 2005, 10:21 AM
[] - Oddysey - Oct. 26, 2005, 07:54 PM
[] - z12 - Oct. 26, 2005, 11:46 PM
[] - Oddysey - Oct. 27, 2005, 03:09 AM
[] - z12 - Oct. 27, 2005, 02:31 PM
[] - Peakaboo - Oct. 30, 2005, 01:41 AM
[] - WildTbag - Oct. 31, 2005, 12:45 AM
[] - Oddysey - Oct. 31, 2005, 02:41 AM
[] - ProxRocks - Oct. 31, 2005, 01:30 PM
[] - laighleas - Nov. 04, 2005, 12:36 PM
[] - laighleas - Nov. 04, 2005, 12:52 PM
[] - laighleas - Nov. 04, 2005, 02:02 PM
[] - Peakaboo - Nov. 04, 2005, 03:17 PM
[] - JJoe - Nov. 04, 2005, 06:08 PM
[] - Kye-U - Nov. 04, 2005, 08:50 PM
[] - ProxRocks - Nov. 04, 2005, 09:39 PM
[] - Peakaboo - Nov. 05, 2005, 03:33 AM
[] - z12 - Nov. 06, 2005, 02:37 PM
[] - laighleas - Nov. 09, 2005, 07:43 PM
[] - laighleas - Nov. 09, 2005, 07:50 PM
[] - JJoe - Nov. 09, 2005, 10:28 PM
[] - laighleas - Nov. 10, 2005 03:03 AM
[] - JJoe - Nov. 10, 2005, 05:45 AM
[] - z12 - Nov. 10, 2005, 10:56 AM
[] - laighleas - Nov. 10, 2005, 12:18 PM
[] - laighleas - Nov. 10, 2005, 12:52 PM
[] - laighleas - Nov. 10, 2005, 01:05 PM
[] - Peakaboo - Nov. 11, 2005, 07:04 PM
[] - z12 - Nov. 12, 2005, 02:18 AM
[] - laighleas - Nov. 12, 2005, 03:55 AM
[] - laighleas - Nov. 12, 2005, 04:56 AM
[] - z12 - Nov. 13, 2005, 07:26 AM
[] - Peakaboo - Nov. 13, 2005, 04:59 PM
[] - z12 - Nov. 13, 2005, 08:34 PM
[] - Oddysey - Nov. 13, 2005, 08:40 PM
[] - Peakaboo - Nov. 13, 2005, 09:23 PM
[] - z12 - Nov. 13, 2005, 10:43 PM
[] - Peakaboo - Nov. 14, 2005, 03:12 AM
[] - laighleas - Nov. 14, 2005, 03:36 PM
[] - Guest - Nov. 14, 2005, 04:32 PM
[] - Oddysey - Nov. 14, 2005, 07:47 PM
[] - Kye-U - Nov. 15, 2005, 12:07 AM
[] - z12 - Nov. 15, 2005, 05:14 PM
[] - Kye-U - Nov. 16, 2005, 06:20 AM
[] - laighleas - Nov. 26, 2005, 03:25 PM
RE: Proxomitron reduces RWIN to 32768 - JJoe - Nov. 26, 2005, 09:55 PM
[] - laighleas - Nov. 27, 2005, 02:16 AM
[] - Kye-U - Nov. 27, 2005, 02:37 AM
[] - Siamesecat - Nov. 27, 2005, 06:50 AM
[] - JJoe - Nov. 27, 2005, 08:25 AM
[] - Peakaboo - Nov. 28, 2005, 03:26 AM
[] - Kye-U - Nov. 28, 2005, 05:00 AM
[] - JJoe - Nov. 28, 2005, 06:17 AM
[] - Siamesecat - Nov. 28, 2005, 07:04 AM
[] - JJoe - Nov. 28, 2005, 01:53 PM
[] - Peakaboo - Nov. 28, 2005, 02:22 PM
[] - JJoe - Nov. 28, 2005, 03:30 PM
[] - JJoe - Nov. 28, 2005, 05:00 PM
[] - Kye-U - Nov. 28, 2005, 09:30 PM
[] - Siamesecat - Nov. 29, 2005, 08:02 AM
[] - JJoe - Nov. 29, 2005, 04:33 PM
[] - Siamesecat - Nov. 29, 2005, 08:14 PM
[] - JJoe - Nov. 30, 2005, 04:49 AM
[] - JJoe - Nov. 30, 2005, 05:12 AM
[] - Siamesecat - Nov. 30, 2005, 07:19 AM
[] - Guest - Nov. 30, 2005, 10:40 AM
[] - toods - Nov. 30, 2005, 12:45 PM
[] - JJoe - Nov. 30, 2005, 03:31 PM
[] - Tony Tough - Nov. 30, 2005, 03:56 PM
[] - Siamesecat - Dec. 01, 2005, 06:34 AM
[] - JJoe - Dec. 01, 2005, 03:33 PM
[] - laighleas - Dec. 01, 2005, 11:45 PM
[] - JJoe - Dec. 02, 2005, 12:56 AM
[] - Oddysey - Dec. 02, 2005, 12:59 AM
[] - Siamesecat - Dec. 02, 2005, 08:23 AM
[] - peakaboo g - Dec. 02, 2005, 02:50 PM
[] - JJoe - Dec. 02, 2005, 03:34 PM
[] - laighleas - Dec. 02, 2005, 04:58 PM
[] - laighleas - Dec. 02, 2005, 05:00 PM
[] - JJoe - Dec. 02, 2005, 11:35 PM
[] - Oddysey - Dec. 03, 2005, 12:03 AM
[] - laighleas - Dec. 03, 2005, 12:13 AM
[] - Siamesecat - Dec. 03, 2005, 07:15 PM
[] - Siamesecat - Dec. 04, 2005, 01:46 AM
[] - JJoe - Dec. 04, 2005, 04:46 AM
[] - Siamesecat - Dec. 04, 2005, 07:06 AM
[] - JJoe - Dec. 04, 2005, 06:11 PM
[] - Siamesecat - Dec. 05, 2005, 06:44 AM
[] - JJoe - Dec. 05, 2005, 09:48 PM
[] - Siamesecat - Dec. 06, 2005, 06:23 AM
[] - JJoe - Dec. 06, 2005, 09:33 PM
[] - Siamesecat - Dec. 07, 2005, 06:00 AM

Forum Jump: