Some help please. My speeds refuse to go up.

[kanenas]

Hello.
I've been trying to improve the transfer speeds but I don't seem to be getting anywhere.
My line speeds were just doubled and now I am on 2048/256 (it actually shows as 2112/288).

The system is XP SP2, the modem is Netgear DG632 (in "modem" mode and uses PPPoA) and the router is a D-Link DGL-4300 running in DHCP mode.
The NIC is an Intel Pro 100/1000 CT in autodetect mode (connects at 1000 to the router).

I set the TCP parameters based on a 350ms delay.

The highest speed I got was at the SG Speed Test (the 1st server on the list - http://www.stoltenb.org/): 1482/230

Servers at other places clock the download speed between 750 - 1050.

------------------

TCP Analyzer shows:

TCP options string = 020405b40103030101010402

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Default TCP Receive Window (RWIN) = 92400
RWIN Scaling (RFC1323) = 1 bits (scale factor of 2)
Unscaled TCP Receive Window = 46200

For optimum performance, consider changing RWIN to a multiple of MSS.
Other RWIN values that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 3696 kbps (462 KBytes/s) @ 200ms
Your TCP Window limits you to: 1478.4 kbps (184.8 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 57 hops
TTL value is ok.

Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 01011100 (92)
Precedence (priority) = 010 (immediate)
Delay = 1 (low delay)
Throughput = 1 (high throughput)
Reliability = 1 (high reliability)
Cost = 0 (normal cost)
Check bit = 0 (correct, 8th checking bit must be zero)

-------------------------

NDT shows:

TCP/Web100 Network Diagnostic Tool v5.3.3d
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 156.58Kb/s
running 10s inbound test (server to client) . . . . . . 1.53Mb/s
Your PC is connected to a Cable/DSL modem

------ 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 = 367.14 msec; the Packet size = 1460 Bytes; and
There were 8 packets retransmitted, 107 duplicate acks received, and 138 SACK blocks received
The connection was idle 0 seconds (0%) of the time
This connection is receiver limited 57.89% of the time.
This connection is network limited 42.08% 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
Packet size is preserved End-to-End
Server IP addresses are preserved End-to-End
Information: Network Address Translation (NAT) box is modifying the Client's IP address
Server says [193.92.229.121] but Client says [192.168.0.2]

---------------------

TCP Otimizer shows (settings have been applied to all NICs):

General Settings tab:
MTU - 1500
TTL - 64
TCP Receive Window -92400
MTU Discovery - Yes
Black Hole Detect - No
Selective Acks - Yes
Max Duplicate ACKs - 2
TCP 1323 Options:
Windows Scaling - checked
Timestamps - unchecked

Advanced Settings tab:
Max Connections per Server - 10
Max Connections per 1.0 Server - 10
LocalPriority - 5
Host Priority - 6
DNSPriority - 7
NetbtPriority - 8
Lan Browsing speedup - optimized
QoS: NonBestEffortLimit - 0
ToS: DisableUserTOSSetting - 0
ToS: DefaultTOSValue - 92
MaxNegativeCacheTtl - 0
NetFailureCacheTime - 0
NegativeSOACache Time - 0
LAN Request Buffer Size - 16384

------------------

Is there anything obviously wrong with my setup?
Any suggestions on how I might improve the above?

Thank you in advance.

[trogers]

My line speeds were just doubled and now I am on 2048/256 (it actually shows as 2112/288).

I set the TCP parameters based on a 350ms delay.

The highest speed I got was at the SG Speed Test (the 1st server on the list - http://www.stoltenb.org/): 1482/230

TCP/Web100 Network Diagnostic Tool v5.3.3d
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 156.58Kb/s
running 10s inbound test (server to client) . . . . . . 1.53Mb/s
Your PC is connected to a Cable/DSL modem

Web100 reports the Round trip time = 367.14 msec; the Packet size = 1460 Bytes; and
There were 8 packets retransmitted, 107 duplicate acks received, and 138 SACK blocks received
The connection was idle 0 seconds (0%) of the time
This connection is receiver limited 57.89% of the time.
This connection is network limited 42.08% of the time.

TCP Receive Window -92400


Your target speed is 90% of 2112 kbps = 1900 kbps. You are actually quiet close to this target when you can achieve almost 1500 kbps when testing all the way from Germany to a US website. You should test at a website within your country to see if you can achieve 1900 kbps.

You made 2 errors in choosing the TCP Receive Window (RWIN).

You have allowed only 350ms without some allowance for varying traffic conditions - the higher the traffic, the higher the latency due to signal queues at the network and international gateway routers.

Your RWIN of 92400 is not an even multiple of MSS.

Use the following custom setting which allows max latency up to 480ms:

General Settings tab:
Custom settings - check
Modify All Network Adapters - check
network adapter selection - your NIC
MTU 1500
TTL - 64
TCP Receive Window -128480
MTU Discovery - Yes
Black Hole Detect - No
Selective Acks - Yes
Max Duplicate ACKs - 2
TCP 1323 Options:
Windows Scaling - check
Timestamps - uncheck
Advanced Settings tab:
Max Connections per Server - 10
Max Connections per 1.0 Server - 20
LocalPriority - 5
Host Priority - 6
DNSPriority - 7
NetbtPriority - 8
Lan Browsing speedup - optimized
QoS: NonBestEffortLimit - 0
ToS: DisableUserTOSSetting - 0
ToS: DefaultTOSValue - 80
MaxNegativeCacheTtl - 0
NetFailureCacheTime - 0
NegativeSOACache Time - 0
LAN Request Buffer Size - 32768
Then select "Apply Changes" and reboot to take effect

[kanenas]

Thank you.
No idea how I missed the MSS-multiple rule.

The delay I used was more or less right. 50% more than the maximum I was getting at the time.
I've tried your suggestions last night but the speed went down a bit.

This morning it was way down. The same results with any TCPWindowSize I tried. I tend to believe that the ISP overloads the line or is just clueless.

TCP Optimizer is set exactly as you described so I will not repeat it.

TCP Analyzer shows:

TCP options string = 020405b40103030101010402

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Default TCP Receive Window (RWIN) = 128480
RWIN Scaling (RFC1323) = 1 bits (scale factor of 2)
Unscaled TCP Receive Window = 64240

RWIN is a multiple of MSS
Other RWIN values that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4)
128480 (MSS x 44 * scale factor of 2) <-- current value
64240 (MSS x 44)

bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 5139.2 kbps (642.4 KBytes/s) @ 200ms
Your TCP Window limits you to: 2055.68 kbps (256.96 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 57 hops
TTL value is ok.

Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 01010000 (80)
Precedence (priority) = 010 (immediate)
Delay = 1 (low delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 0 (normal cost)
Check bit = 0 (correct, 8th checking bit must be zero)

-----------------------

NDT running in a neighboring city (but older version) shows:

TCP/Web100 Network Diagnostic Tool v5.2.1e
click START to begin
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 261.50Kb/s
running 10s inbound test (server to client) . . . . . . 491.20kb/s
Your PC is connected to a Cable/DSL modem

click START to re-test
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 261.50Kb/s
running 10s inbound test (server to client) . . . . . . 457.59kb/s
Your PC is connected to a Cable/DSL modem
Information: Other network traffic is congesting the link

click START to re-test

-------------------------

NDT in the States:

TCP/Web100 Network Diagnostic Tool v5.3.3d
click START to begin
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 244.99Kb/s
running 10s inbound test (server to client) . . . . . . 440.69kb/s
Your PC is connected to a Cable/DSL modem
Information: The receive buffer should be 511.61 Kbytes to maximize throughput

click START to re-test
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 245.01Kb/s
running 10s inbound test (server to client) . . . . . . 378.88kb/s
Your PC is connected to a Cable/DSL modem
Information: Other network traffic is congesting the link

click START to re-test

------------------------

SG Speed Test:

483 kbps down (~0.48 Mbps, 59 KB/s)↓
201 kbps up (~0.2 Mbps, 25 KB/s)↑
1024 KB downloaded in 17.385 seconds
100 KB uploaded in 4.066 seconds
Tested on: 2006-10-09 03:59 EDT

--------------------

On the US NDT results I keep seeing a comment about increasing the Receive Buffer.
Which buffer is that? RWIN, Default RWIN or something else?

The other recurring theme is the "traffic congestion" but I don't see what I can do about it.

Thanks again for the help.

[trogers]

The delay I used was more or less right. 50% more than the maximum I was getting at the time.
I've tried your suggestions last night but the speed went down a bit.

This morning it was way down. The same results with any TCPWindowSize I tried. I tend to believe that the ISP overloads the line or is just clueless.

NDT running in a neighboring city (but older version) shows:

TCP/Web100 Network Diagnostic Tool v5.2.1e
click START to begin
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 261.50Kb/s
running 10s inbound test (server to client) . . . . . . 491.20kb/s
Your PC is connected to a Cable/DSL modem

click START to re-test
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 261.50Kb/s
running 10s inbound test (server to client) . . . . . . 457.59kb/s
Your PC is connected to a Cable/DSL modem
Information: Other network traffic is congesting the link

On the US NDT results I keep seeing a comment about increasing the Receive Buffer.
Which buffer is that? RWIN, Default RWIN or something else?

The other recurring theme is the "traffic congestion" but I don't see what I can do about it.


If your average delay to the US is about 240ms and your NDT test shows 360+, either your ISP's network is rather busy during the period you did the test or you have a weak signal line.

Increasing the Receive buffer (which is the same as TCP Receive Window or RWIN in TCP Analyzer and Optimizer) will not increase speed but only increase delay.

Recalculate the correct RWIN

2112 x 360 / 8 = 95040

Equate to the nearest even multiple of MSS

95040/1460 = 65.10

Use RWIN = 1460 x 66 = 96360

If the high delay is due to network traffic, you would be able to achieve delay lower than 240ms during 4-6am period. If you consistently get a high delay, your cable line or splitter may be the suspect.

Here is a speedtest site with a server in Germany:

http://www.mondospeed.com/speedtest/

[kanenas]

It looks like nothing is wrong with your recommendations.

I called the ISP and it seems there's a problem with the local phone monopoly. They are in the process of reconfiguring their DSLAMs to cover the recent doubling of speed. It's expected to be unstable until the end of the month.

I'll put this on the backburner and pick it up again if the problem reoccurs next month.

Much appreciated for youe help.