- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Last night was working fine with download speed at >20 mps. This afternoon, log on and everything is lagging. Check speed and it is fluctuating between .8 mps and 6 mps. I have changed no settings on my end. Have any ideas?
Here is the speedtest info ( I x'd out the IP addresses):
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
SendBufferSize set to [8192]
running 10s outbound test (client to server) . . . . . 6.28Mb/s
running 10s inbound test (server to client) . . . . . . 12.70kb/s
------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.6.0_21
------ Web100 Detailed Analysis ------
Client Receive Window detected at 17520 bytes.
45 Mbps T3/DS3 link found.
Link set to Full Duplex mode
Information: throughput is limited by other network traffic.
Good network cable(s) found
Normal duplex operation found.
Web100 reports the Round trip time = 556.73 msec; the Packet size = 1460 Bytes; and
There were 8 packets retransmitted, 8 duplicate acks received, and 0 SACK blocks received
The connection stalled 4 times due to packet loss
The connection was idle 19.57 seconds (57.55%) of the time
This connection is network limited 98.97% 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
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 [XXX.XX.XX.XXX] but Client says [XXX.XXX.X.X]
Solved! Go to Correct Answer
Correct answers
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If the STB can see the router (for guide and VoD) then the ECB should be able too as well ... but you're right that the amount of data is probably less than what the ECB will drive. So, I'm thinking it's worth isolating to just the ONT, splitter, router, and ECB for the moment and see if the problems goes away ... if so, you've got noise being introduced somewhere that's causing issues with the ECB to router connection. If it's all local and still having issues -- then one or the other pieces of electronics has decided to take a field trip.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
These are not good things to see ....
Web100 reports the Round trip time = 556.73 msec; the Packet size = 1460 Bytes; and
There were 8 packets retransmitted, 8 duplicate acks received, and 0 SACK blocks received
The connection stalled 4 times due to packet loss
High latency with packet loss and duplicate acks. First try is a reset of the router and/or the ONT and if the problem persists, something worth reporting as a trouble. Would be nice to see a "netstat -e" run on the system exhibiting the problems.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Reset the router, no improvement:
Analysis information:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
SendBufferSize set to [8192]
running 10s outbound test (client to server) . . . . . 5.91Mb/s
running 10s inbound test (server to client) . . . . . . 2.33Mb/s
------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.6.0_21
------ Web100 Detailed Analysis ------
Client Receive Window detected at 17520 bytes.
45 Mbps T3/DS3 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 = 28.28 msec; the Packet size = 1460 Bytes; and
There were 24 packets retransmitted, 334 duplicate acks received, and 52 SACK blocks received
The connection stalled 2 times due to packet loss
The connection was idle 0.49 seconds (4.08%) of the time
This connection is receiver limited 16.05% of the time.
Increasing the the client's receive buffer (17.0 KB) will improve performance
This connection is sender limited 19.58% of the time.
This connection is network limited 64.36% 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: OFF
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 [XXXXXXXXXX] but Client says [XXXXXXXXXXXXX]
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Assuming you're hard wired to the router here for these test ... just to keep in the air interference out of the picture.
These stats are killers ....
There were 24 packets retransmitted, 334 duplicate acks received, and 52 SACK blocks received
The connection stalled 2 times due to packet loss
I would try an ONT reset next ...
Power down the PC, power down the router, detech the battery from the ONT power supply, then unplug the ONT power supply and wait about 1 minute before reconnecting the power supply and then the battery backup, wait about a minute and then power up the router, wait about another minute and then power up the PC and run your tests.
A "netstat -e" run in a command window on the PC would be useful as would a "tracert www.google.com"
.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just to clarify. I'm running internet from a splitter from coax using a Actiontec ECB2200.
OK, I did as was recommended:
Analysis information:
Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
SendBufferSize set to [8192]
running 10s outbound test (client to server) . . . . . 6.26Mb/s
running 10s inbound test (server to client) . . . . . . 411.45kb/s
------ Client System Details ------
OS data: Name = Windows XP, Architecture = x86, Version = 5.1
Java data: Vendor = Sun Microsystems Inc., Version = 1.6.0_21
------ Web100 Detailed Analysis ------
Client Receive Window detected at 17520 bytes.
45 Mbps T3/DS3 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 = 68.54 msec; the Packet size = 1460 Bytes; and
There were 14 packets retransmitted, 136 duplicate acks received, and 18 SACK blocks received
The connection stalled 3 times due to packet loss
The connection was idle 9.0 seconds (50.0%) of the time
This connection is receiver limited 1.92% of the time.
Increasing the the client's receive buffer (17.0 KB) will improve performance
This connection is sender limited 3.20% of the time.
This connection is network limited 94.87% 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
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
tracert www.google.com returns:
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\Scott_2>tracert www.google.com
Tracing route to www.l.google.com [72.14.204.104]
over a maximum of 30 hops:
1 2800 ms 4173 ms 2767 ms 192.168.1.1
2 11 ms 12 ms 10 ms L100.WASHDC-VFTTP-99.verizon-gni.net [70.110.24.
1]
3 12 ms 12 ms 10 ms G2-0-6-899.WASHDC-LCR-08.verizon-gni.net [130.81
.110.154]
4 11 ms 9 ms 10 ms so-1-1-0-0.RES-BB-RTR2.verizon-gni.net [130.81.2
9.2]
5 14 ms 13 ms 15 ms 0.so-1-2-0.XL4.IAD8.ALTER.NET [152.63.37.121]
6 21 ms 23 ms 21 ms 0.so-1-0-1.XL4.NYC4.ALTER.NET [152.63.1.170]
7 20 ms 18 ms 19 ms TenGigE0-7-1-0.GW8.NYC4.ALTER.NET [152.63.21.125
]
8 29 ms 19 ms 19 ms google-gw.customer.alter.net [152.179.72.62]
9 34 ms 104 ms 30 ms 209.85.252.215
10 23 ms 67 ms 20 ms 209.85.249.11
11 24 ms 22 ms 44 ms 209.85.248.222
12 23 ms 21 ms 42 ms 66.249.94.46
13 21 ms * 43 ms iad04s01-in-f104.1e100.net [72.14.204.104]
Trace complete.
netstat -e returns:
C:\Documents and Settings\Scott_2>netstat -e
Interface Statistics
Received Sent
Bytes 3905347 8822979
Unicast packets 10460 13026
Non-unicast packets 282 69
Discards 0 0
Errors 0 0
Unknown protocols 0
C:\Documents and Settings\Scott_2>
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Lasagna's comment reminded me that I hadn't tested my Actiontec network adapter. Soooooo, I moved my computer to the router, plugged it in directly and got 30 mps down, 7 up. So it looks like my Actiontec died after 25 days.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Since this going across coax, etc. we should move the adapter close to the router (one split) and do test again. It could be a bad splitter or cable run.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, when I get home I'll attach directly to the cable from which it is split. That's about as close to it as I can get(I'm renting a room and don't have access to any other cable access points). I would love it to be the splitter because I'm thinking it will take at least three weeks to get the ActionTec back from Amazon and it needs to be mailed this afternoon. Big headache.
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've had my unit now for about a year and it works great ... while it's certainly possible you got a bad one, I just think it's worth ruling out the cable plant before you have to wait out a product exchange only to find out that there's something going on with the local cable plant -- for instance, I had someone complain about service being disrupted every evening when their son came home and went to watch TV -- turned out he had a DVD recorder hooked up the wrong way and was shooting an RF signal back into the cable plant (had the in/out reversed).
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@bangorme wrote:Ok, when I get home I'll attach directly to the cable from which it is split. That's about as close to it as I can get(I'm renting a room and don't have access to any other cable access points). I would love it to be the splitter because I'm thinking it will take at least three weeks to get the ActionTec back from Amazon and it needs to be mailed this afternoon. Big headache.
(Clue) "ActionTec back from Amazon"?
If you have more than one Actiontec on the coax and you are renting a room. That could be the issue. Try to disable the WAN, DHCP, and let the main router control everything. This would allow the Actiontec to run as a bridge. If you are wanting your own network, then I would sugest connecting a second router to the Actiontec to handle that. Also if you could get a NIM-100 to convert the MOCA to ethernet, you could use the Ethernet WAN port on the Actiontec and set it up for DHCP to get an address from the main routers LAN. Right now it looks as if you might have two MOCA routers fighting for control of the coax.