Jump to content
Sign in to follow this  
cholla

Cablenut & RWIN question for XP

Recommended Posts

I still don't understand why all three of these settings are not set the same in XP since they all appear to set the RWIN: DefaultReceiveWindow ,GlobalMaxTcpWindowSize,& TcpWindowSize.

When someone posts a screen shot of their cablenut Manual tweak screen usually these settings are different from each other.

Another question ROM-DOS added a 0 to some of his cablenut settings some of this was to the 3 above but also these 2 below .He is testing way above his "cap" on dial-up.These 2 should be wrong

Share this post


Link to post
Share on other sites

VanBuren: I had read the definitions I still don't understand why thw RWIN value is not the same for all 3.for example:

GlobalMaxTcpWindowSize=128480

TcpWindowSize=128480

DefaultReceiveWindow =128480

instead of this for example this is from ROM-DOS's cablenut screen shot

GlobalMaxTcpWindowSize=87600

TcpWindowSize=87600

DefaultReceiveWindow =128840

I asked Van because he's the cablenut expert but if someone else want's to reply it's ok.

Share this post


Link to post
Share on other sites

DefautReceivewindow is a AFD parameter and GlobalMaxTcpWindowsize, TcpWindowsize is a TCPIP parameter

If you have windows XP SP2 installed, TCP analyzers will read your DefaultReceiveWindow as TcpWindowsize (RWIN). and with 2k / XP SP1 the analyzer will only read TcpWindowsize.

below is a explenation on how AFD tweaking works, and why AFD parameters dont have to be multiple with MSS

quote from http://smallvoid.com/tweak/winnt/network.html#AFD_WINDOW

"In the WinNT network architecture a layer is placed on top of the TCPIP layer called AFD(Ancillary Function Driver for Winsock). The AFD provides the winsock interface, which is used by most network applications in Windows and is also supporting things like DNS and DHCP.

The AFD provides two windows which acts as a flowcontrol for the application creating the socket:

    * AFD-Send-Window: Used when the application is sending data over a connection, if if more data is sent than the receiver is able to acknowledge then the AFD-Send-Window will block the transfer for the application, when it reaches the limit of the AFD-Send-Window.

    * AFD-Receive-Window: Used when the application is receiving data over a connection, if the application is not able to receive data fast enough or is blocked by other processing which keeps it from receiving data, then the AFD-Receive-Window will act as a buffer until it reaches the limit of the AFD-Receive-Window, where it will then block the remote-application from sending data.

The two default AFD-Windows is by default self tuning using the following values depending on the total amount of RAM detected. When an application creates a socket it can specify a different AFD-Window than the default.

    * Default AFD Send- & Receive-Window = 4096 Bytes (If less than 19 MByte RAM)

    * Default AFD Send- & Receive-Window = 8192 Bytes (If more than 19 MByte RAM)

In the scenario where using a network with high latency or high bandwidth the AFD-Send-Window will constantly be blocking the application's transfer if the AFD-Send-Window is set too low. The AFD-Send-Window should have the same value as the optimal TCPIP-Receive-Window to get the best upload-speed.

In the scenario where using an application which is not able to handle situations where the data is being sent in bursts. Then increasing the AFD-Receive-Window will allow to smooth out the bursts, and avoid blocking the remote-application sending and will increase the overall download speed. Also making sure that the window is larger than any reply being sent back will avoid blocking of the sender of the reply, as it has to wait for ACK to complete it's reply.

To set the default size of the AFD-Windows use the following DWORD registry keys :

[HKEY_LOCAL_MACHINE SYSTEM CurrentControlSet Services Afd Parameters]

DefaultReceiveWindow = 16384

DefaultSendWindow = 16384

Note that the AFD-Windows should be rounded to a multiple of page size(Usually 4096 Bytes). Not a multiple of the Maximum Segment Size(MSS) which is recommended for the TCPIP-Window.

Note that applications which specifies their own AFD-Windows for each of their sockets by using setsockopt and specifying a new value for the SO_RCVBUF parameter (Not possible for RPC services), will not be affected by changing the default AFD-Windows.

Related : Recommended settings for the TCP/IP stack

More info MS KB Q214397

More info MS KB Q246984"

VanBuren :)

Share this post


Link to post
Share on other sites

its multiple with 1024, thats the recommendations cablenut team gives, but after todays research i think multiple with 4096 is more correct

however, i dont think you will notice any speed improvements by divide 384000 in 4096 to get an even multiple value...

VanBuren :)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...