Limited network connection & Excessive packet loss problem

[tlbray]

I hope someone here can help me with this. I used to get speeds of over 2Mbps using a Realtek 3189 NIC but somehow it stop funtioning properly and I haven't been able to DL the most recent drivers, so I switched over to the adapter on my motherboard.

I'm using a VisionNet ADSL W706 Modem and an internal VIA Rhine II Fast Ethernet Adapter. I have run numerous tests with the adapter set to Auto-Negotiation, 10BaseT Half & Full Duplex. I still get the same reports that my network is limited and excessive packet loss is impacting my connections performance. Here's the latest report from netspeed.stanford.edu:

WEB100 Enabled Statistics:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 871.62Kb/s
running 10s inbound test (server to client) . . . . . . 190.23kb/s

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

------ 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 = 133.88 msec; the Packet size = 1380 Bytes; and
There were 38 packets retransmitted, 27 duplicate acks received, and 43 SACK blocks received
The connection stalled 3 times due to packet loss
The connection was idle 1.09 seconds (10.90%) of the time
This connection is network limited 99.81% of the time.
Excessive packet loss is impacting your performance, check the auto-negotiate function on your local PC and network switch

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: OFF
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


Any help would be greatly appreciated!

[mccoffee]

did you try replacing the cables?

[trogers]

Network based limits usually means traffic in your ISP network is high compared to the available bandwidth in the network. And excessive packet losses, usually means a line quality problem or may occur when your RWIN (Tcp Buffer) is set too high.

Your Nic should be set to auto. If the test result shows "Normal duplex operation found" then there is no duplex mismatch and no further changes is needed on your adapter.

Do the TCP Analyzer test and let's have a look at your MTU and RWIN values. Your MSS is shown as 1380 and thus your MTU is only 1420. This is rather low and should be raised as high as possible.

[tlbray]

I have tried manually set my MTU and the registry says that my MTU is 1500, yet the analyser reports differently:

TCP options string = 0204056401010402
MTU = 1420
MTU is not fully optimized for broadband. Consider increasing your MTU to 1500 for better throughput. If you are using a router, it could be limiting your MTU regardless of Registry settings.
MSS = 1380
MSS is not optimized for broadband. Consider increasing your MTU value.

Default TCP Receive Window (RWIN) = 32120
RWIN Scaling (RFC1323) = 0 bits
Unscaled TCP Receive Window = 32120

For optimum performance, consider changing RWIN to a multiple of MSS.
Other values for RWIN that might work well with your current MTU/MSS:
507840 (MSS x 46 * scale factor of 8)
253920 (MSS x 46 * scale factor of 4)
126960 (MSS x 46 * scale factor of 2)
63480 (MSS x 46)
bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 1284.8 kbps (160.6 KBytes/s) @ 200ms
Your TCP Window limits you to: 513.92 kbps (64.24 KBytes/s) @ 500ms
MTU Discovery (RFC1191) = ON
Time to live left = 52 hops

TTL value is ok.
Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON
IP type of service field (RFC1349) = 00000000 (0)

[trogers]

Philips,

I am not good with advice on modifying MTU, especially if they are limited by switching devices - "Information: Network Middlebox is modifying MSS variable". Please assist this case.

[trogers]

Download the TCP Optimizer and these setting. Then retest with TCP Analyzer:

General Settings tab:
Custom settings - check
Modify All Network Adapters - check
network adapter selection - your NIC
MTU - 1500
TTL - 64
TCP Receive Window - blank
MTU Discovery - Yes
Black Hole Detect - No
Selective Acks - Yes
Max Duplicate ACKs - 2
TCP 1323 Options:
Windows Scaling - uncheck
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 - 240
MaxNegativeCacheTtl - 0
NetFailureCacheTime - 0
NegativeSOACache Time - 0
LAN Request Buffer Size - 32768
Then select "Apply Changes" and reboot to take effect

[mccoffee]

Look at your adapters properties in my network places see if there is an mtu option in there if you are using a pppoe connection using software to connection look at the pppoe properties of that connection sometimes there is an mtu setting there as well.

Try this even if we get the mtu to 1480 it will work just as good http://dslnuts.com/pppoe/mtustuck.htm

[trogers]

Looks like we have to go by the old-fashion way.

Call out your DOS black screen and after C:\ use this command

ping -f -l (max value) www.testmy.net

Where -l is minus small L and max value is your largest anticipated MTU value minus 28.

Say you start with assumed MTU value of 1500, max value is 1500-28 = 1472

If you get a message "Packets need to be fragmented..." Then 1500 is not your largest MTU.

Go on pinging with a max value less 1 until you get a proper result like "Reply from XX.XXX.XX.XXX: bytes= ______ time = _____ ms TTL= ___

The bytes value shown + 28 = your largest MTU.