Sharky2006 Posted January 16, 2006 CID Share Posted January 16, 2006 I ran the following test....from 1) JLab Web100 based Network Diagnostic Tester (NDT) *Which states that ...This connection is receiver limited 85.61% of the time. Quote Link to comment Share on other sites More sharing options...
FallowEarth Posted January 16, 2006 CID Share Posted January 16, 2006 Hmmm....read here about the Nagle algorithm: http://www.testmy.net/forum/index.php?topic=8818.0 And I couldn't find it in your previous posts, can you please try THIS TEST and post results? Quote Link to comment Share on other sites More sharing options...
Sharky2006 Posted January 16, 2006 Author CID Share Posted January 16, 2006 Here are the results....Does it look ok.? TCP options string = 020405ac0103030101010402 MTU = 1492 MTU is optimized for PPoE DSL broadband. If not, consider raising MTU to 1500 for optimal throughput. MSS = 1452 MSS is optimized for PPPoE DSL broadband. If not, consider raising your MTU value. Default Receive Window (RWIN) = 124800 RWIN Scaling (RFC1323) = 1 bits (scale factor of 2) Unscaled Receive Window = 62400 For optimum performance, consider changing RWIN to a multiple of MSS. Other values for RWIN that might work well with your current MTU/MSS: 511104 (MSS x 44 * scale factor of 255552 (MSS x 44 * scale factor of 4) 127776 (MSS x 44 * scale factor of 2) 63888 (MSS x 44) bandwidth * delay product (Note this is not a speed test): Your RcvWindow limits you to: 4992 kbps (624 KBytes/s) @ 200ms Your RcvWindow limits you to: 1996.8 kbps (249.6 KBytes/s) @ 500ms MTU Discovery (RFC1191) = ON Time to live left = 55 hops TTL value is ok. Timestamps (RFC1323) = OFF Selective Acknowledgements (RFC2018) = ON IP type of service field (RFC1349) = 00000000 (0) Quote Link to comment Share on other sites More sharing options...
cholla Posted January 16, 2006 CID Share Posted January 16, 2006 Sharky2006 ;I'm going to let FallowEarth help you for the most part .The NDT tests are a guide at best.this part you ask about is your RWIN setting " Increasing the current receive buffer (121.0 KB) will improve performance This connection is network limited 14.34% of the time." I have dial-up & this test never tells you your RWIN is large enough.That being said it does some usuable readings I will put in a lint to some topics on interpreting the test results. On the speedguide test it says you should change your rwin to127776 so it is a multiple of your MSS.There are 4 RWIN settings in XP & all of them do not use the MSS as the multiplier. http://www.testmy.net/forum/index.php?topic=9537.0 http://www.testmy.net/forum/index.php?topic=9538.0 Quote Link to comment Share on other sites More sharing options...
FallowEarth Posted January 16, 2006 CID Share Posted January 16, 2006 *Which states that ...This connection is receiver limited 85.61% of the time. Quote Link to comment Share on other sites More sharing options...
Sharky2006 Posted January 16, 2006 Author CID Share Posted January 16, 2006 How do I change my rwin to127776? Quote Link to comment Share on other sites More sharing options...
Sharky2006 Posted January 16, 2006 Author CID Share Posted January 16, 2006 I am going to change it now in cablenut to 255552.... Quote Link to comment Share on other sites More sharing options...
Sharky2006 Posted January 16, 2006 Author CID Share Posted January 16, 2006 How do I increase the "....unscaled receive window" ? By the way, I thank you in advance....for everything.... You may want to take a look at my post about cleaning your computer. I created a batch file that works wonders for me and if you need any help with it, let me know.... Quote Link to comment Share on other sites More sharing options...
cholla Posted January 16, 2006 CID Share Posted January 16, 2006 When setting the RWIN in XP this is some good information. AFD(Ancillary Function Driver for Winsock http://support.microsoft.com/kb/Q214397 http://support.microsoft.com/kb/Q246984 http://support.microsoft.com/kb/Q314053#top 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. EDIT: To make this clearer the settings right below are examples .They would be good for some OS's but you need to calculate the correct one for yours. 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(Example) DefaultSendWindow = 16384(Example) 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. DefaultReceiveWindow - The number of receive bytes that AFD buffers on a connection before imposing flow control. For some applications, a larger value here gives slightly better performance at the expense of increased resource utilization. Value Type: REG_DWORD Default: 4096/8192/8192 DefaultSendWindow - This is similar to DefaultReceiveWindow, but for the send side of connections. Value Type: REG_DWORD Default: 4096/8192/8192 GlobalMaxTcpWindowSize - The TcpWindowSize parameter can be used to set the receive window on a per-interface basis. This parameter can be used to set a global limit for the TCP window size on a system-wide basis. Value Type: REG_DWORD Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.