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.
  Increasing the current receive buffer (121.0 KB) will improve performance
This connection is network limited 14.34% of the time."

How do I fix this? [/color] (See stats below)
 


WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . .  Done
running 10s outbound test (client to server) . . . . . 447.32kB/s
running 10s inbound test (server to client) . . . . . . 1.50Mb/s

   ------  Client System Details  ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.5.0_01

   ------  Web100 Detailed Analysis  ------
Cable modem/DSL/T1 link found.
Link set to Full Duplex mode
No network congestion discovered.
Good network cable(s) found
Normal duplex operation found.

Web100 reports the Round trip time = 597.26 msec; the Packet size = 1380 Bytes; and
No packet loss was observed.
This connection is receiver limited 85.61% of the time.
  Increasing the current receive buffer (121.0 KB) will improve performance
This connection is network limited 14.34% of the time.

    Web100 reports TCP negotiated the optional Performance Settings to:
RFC 2018 Selective Acknowledgment: ON
RFC 896 Nagle Algorithm: ON
RFC 3168 Explicit Congestion Notification: OFF
RFC 1323 Time Stamping: OFF
RFC 1323 Window Scaling: ON
Information: Network Middlebox is modifying MSS variable
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
   Server says [70.111.*.*] but Client says [192.168.*.*]


<edit> IP

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)

I think this is referring to RWIN.

In your cablenut adjust window, try changing DefaultReceiveWindow to 255552, save to reg, reboot.

Cholla, you speedy guns

I am going to change it now in cablenut to 255552....

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—Number of bytes

Valid Range: 0–0x3FFFFFFF

Default: This parameter does not exist by default.

TcpWindowSize - This parameter determines the maximum TCP receive window size offered by the system. The receive window specifies the number of bytes a sender may transmit without receiving an acknowledgment. In general, larger receive windows will improve performance over high (delay * bandwidth ) networks. For highest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS).

Value Type: REG_DWORD—number of bytes

Valid Range: 0–0x3FFFFFFF


 LargeBufferSize - The size, in bytes, of large buffers used by AFD. Smaller values use less memory and larger
values can improve performance.

Value Type: REG_DWORD

Default: PAGE_SIZE (4096 bytes on i386, 8192 bytes on
 MediumBufferSize - The size in bytes of medium buffers used by AFD.

Value Type: REG_DWORD

Default: 1504
SmallBufferSize - The size in bytes of small buffers used by AFD.

Value Type: REG_DWORD

Default: 128 "
This is another link with some good information I got from Van Buren :
http://smallvoid.com/tweak/winnt/network.html#AFD_WINDOW