U

Visitor

 • 

6 Messages

Wednesday, August 24th, 2022 3:45 PM

Closed

Significant packet loss

Hello there! There have been a couple of outages over the past week, and while the speed of my connection seems good, there is significant packet loss which is really messing with the connectivity. I have included a ping log and a pathping. I also see the packet loss when I use the "Test Connectivity Results" on the gateway itself.

$ ping -v www.comcast.net
PING e7010.dscg.akamaiedge.net (23.202.215.44) 56(84) bytes of data.
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=1 ttl=52 time=20.4 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=3 ttl=52 time=49.3 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=4 ttl=52 time=31.4 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=5 ttl=52 time=19.8 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=7 ttl=52 time=51.8 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=8 ttl=52 time=18.9 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=9 ttl=52 time=17.3 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=10 ttl=52 time=25.4 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=12 ttl=52 time=26.4 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=13 ttl=52 time=83.8 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=15 ttl=52 time=66.5 ms
64 bytes from a23-202-215-44.deploy.static.akamaitechnologies.com (23.202.215.44): icmp_seq=16 ttl=52 time=36.0 ms
^C
--- e7010.dscg.akamaiedge.net ping statistics ---
16 packets transmitted, 12 received, 25% packet loss, time 15361ms
rtt min/avg/max/mdev = 17.258/37.240/83.770/20.402 ms

and

> pathping www.comcast.net

Tracing route to e7010.dscg.akamaiedge.net [23.202.215.44]
over a maximum of 30 hops:
  0  THINKPAD-G9.home.local [192.168.1.118]
  1  192.168.1.1
  2  10.61.156.66
  3  69.139.184.81
  4     *        *     69.139.202.230
  5     *        *        *
Computing statistics for 100 seconds...
            Source to Here   This Node/Link
Hop  RTT    Lost/Sent = Pct  Lost/Sent = Pct  Address
  0                                           THINKPAD-G9.home.local [192.168.1.118]
                                0/ 100 =  0%   |
  1    2ms     0/ 100 =  0%     0/ 100 =  0%  192.168.1.1
                               30/ 100 = 30%   |
  2  ---     100/ 100 =100%    70/ 100 = 70%  10.61.156.66
                                0/ 100 =  0%   |
  3   35ms    31/ 100 = 31%     1/ 100 =  1%  69.139.184.81
                                0/ 100 =  0%   |
  4   33ms    30/ 100 = 30%     0/ 100 =  0%  69.139.202.230

Trace complete.

I have power-cycled several times and it doesn't seem to help. Any suggestions?

Gold Problem Solver

 • 

26K Messages

2 years ago

... there is significant packet loss  ...

End-to-end "Ping" is not a good tool for exploring packet loss. All it tells you is that, somewhere along the route a packet either failed to be passed to the final hop, or a reply from the final hop didn't make it back to the source in time. And I'm puzzled why Ping didn't report "Request timed out" for the four packets that were "lost".

Traceroute (Windows"tracert") and pathping are better, but you must keep in mind that what they report as "packet loss" is a failure of the device at a particular hop to reply to you in a timely way. That's the case with the Pathping you posted. Note that all the packets you sent were replied to by the destination device, and all of the replies from the destination were returned to you. That tells us that only packets that were "lost" where replies from the intermediate hops. But these might not actually have been lost: they might not have been sent at all if the device at one of those hops was too busy to respond and/or was configured to give low priority to trace packets.

Please see https://www.dslreports.com/faq/14068.

Edit: Added "End-to-end"

Please be aware that there are 2 kinds of responses in this Forum: Replies and Comments. When you Comment on a post by scrolling down to "Comment on this post here...", I am notified of your response. But if you select Reply, I am NOT notified and may not be aware of your response.

(edited)

Visitor

 • 

6 Messages

@BruceW​ Thank you Bruce for that helpful information. It definitely feels like packets are getting lost ... I'll hang on some DNS queries, and I'm getting quite a few SSL handshake errors that go away if I just reload.

Do you have any suggestions for how I might communicate this to the Xfinity powers-that-be to see if there's anything they can diagnose or identify?

Thanks again for your response, I appreciate it.

Gold Problem Solver

 • 

26K Messages

2 years ago

... I'll hang on some DNS queries, and I'm getting quite a few SSL handshake errors ...

Those both sound like garden variety connection problems, see below.

... Do you have any suggestions for how I might communicate this to the Xfinity powers-that-be to see if there's anything they can diagnose or identify? ...

You'd need very strong evidence to get their attention, and I don't think you have it yet. Are you connecting via Wifi or Ethernet? If Wifi, it's best to switch to an Ethernet cable connection if possible for testing. That would allow you to determine whether the problem is the Wifi signal or the link between your modem or gateway and Comcast's network. Network connection problems that affect both Ethernet and Wifi devices are often due to poor coax connections or damaged coax cable, usually in or near your home. I have no idea if that's where the problem is, but we have to start somewhere!

If you want to troubleshoot this yourself, please see Internet Troubleshooting Tips. If you still need help, please post your Internet plan speed and the following information from your modem or gateway (from http://192.168.100.1 or http://10.0.0.1):

  • model number
  • downstream: power levels, SNR, and error counts
  • upstream: power levels
  • event log, if available (Be sure to remove or blot out any MAC addresses. Forum security processing considers them "personal information" and may prevent the event log from posting if these are present.)
Please be aware that there are 2 kinds of responses in this Forum: Replies and Comments. When you Comment on a post by scrolling down to "Comment on this post here...", I am notified of your response. But if you select Reply, I am NOT notified and may not be aware of your response.

Visitor

 • 

6 Messages

2 years ago

@BruceW​ Good advice all around. I've been in IT long enough to realize that the most likely cause is something I've screwed up with routing rules or bad cables, but to eliminate that cause I'm connecting directly to the gateway via Ethernet and still seeing the behavior. I've started a Twitter DM conversation with @XfinitySupport and we haven't uncovered anything yet. The only thing that was unusual was that the agent kept sending reset messages to the modem and it didn't respond -- it would show that the modem was reset and rebooted, but in reality nothing happened.

To cover my bases and get as many eyeballs on this as possible, here's the info from the gateway.

Model: CGM4331COM

Downstream:

Power Level SNR 
10.3 dBmV   43.8 dB
9.6 dBmV    42.9 dB
9.9 dBmV    43.9 dB
9.8 dBmV    41.9 dB
9.8 dBmV    41.3 dB
9.9 dBmV    44.0 dB
10.1 dBmV   42.2 dB
10.2 dBmV   42.5 dB
10.3 dBmV   43.7 dB
10.4 dBmV   43.1 dB
10.6 dBmV   43.5 dB
10.7 dBmV   42.9 dB
10.6 dBmV   43.8 dB
10.6 dBmV   43.8 dB
10.7 dBmV   44.1 dB
10.6 dBmV   43.5 dB
10.6 dBmV   43.8 dB
10.5 dBmV   41.7 dB
10.5 dBmV   42.3 dB
10.5 dBmV   43.3 dB
10.4 dBmV   43.7 dB
10.3 dBmV   43.8 dB
10.4 dBmV   43.0 dB
10.2 dBmV   43.9 dB
10.1 dBmV   43.1 dB
10.2 dBmV   43.1 dB
10.0 dBmV   42.5 dB
10.1 dBmV   42.5 dB
10.1 dBmV   43.5 dB
10.1 dBmV   42.8 dB
10.0 dBmV   43.4 dB
9.9 dBmV    42.2 dB
10.1 dBmV   42.8 dB

(no errors to speak of, just 24 Correctable Codewords on a couple of the indexes)

Upstream:

Power Level 
42.0 dBmV
41.3 dBmV
40.8 dBmV
40.0 dBmV
42.8 dBmV
39.0 dBmV

Nothing in event log.

So, I don't see a smoking gun, do you? Hmmm.

Visitor

 • 

6 Messages

2 years ago

Also, I think you're right on connection issue vs. packet loss. For example, it might take me three or four tries to establish a Spotify stream, but once it's locked in it seems pretty steady, at least for the duration of a song.

Visitor

 • 

6 Messages

2 years ago

One more look at the data, here's what PingPlotter looks like. When it can make a connection, the latency is awesome, but you can see all the red bars where the connection is not being made. This results in a lot of connection retries and when I'm trying to establish something like a video conference with lots of back and forth with the servers, it fails.

Ever since there were a couple of outages in the area and Comcast was doing some "infrastructure improvements", I've seen this behavior. We also have a dedicated distribution box at the curb. Do you think it's worth having a tech come out to just check things out?

Gold Problem Solver

 • 

26K Messages

2 years ago

... I don't see a smoking gun, do you? ...

No. The power levels are a bit high, but I doubt if they are high enough to cause problems. Still, you might try adding a 2-to-1 (3.5dB) splitter in front of the modem to see if that changes anything. I'd also recommend you try traces to hosts other than "www.comcast.net". That host does not appear to do anything except redirect to "www.xfinity.com". A non-Comcast host like "www.google.com" for example might be a better choice.

... here's what PingPlotter looks like ...

I'm puzzled by the second hop (IP 10.61.x.y) in that trace. Note that essentially all of the packet loss is occurring at that point. It's a private IP, is that a device under your control? If it's a Comcast device then yes, you should call them in to figure this out. Be aware that if their tech finds bad coax, splitters, amplifiers, or connections in your home (even if Comcast originally supplied them) you'll probably have to pay for the visit ($70-$100) unless you have their Service Protection Plan ( https://www.xfinity.com/support/articles/service-protection-plan, closed to customers that don't already have it). If the trouble is due to a faulty Comcast rental device or anything outside your home you shouldn't be charged.

(edited)

Visitor

 • 

6 Messages

2 years ago

My Internet is back! Here's what happened for those of you in the future that have stumbled onto this thread from a forum search.

@BruceW pretty much nailed it -- the problem ended up being the downstream power levels. I had a tech come out and he was great about going step-by-step from the road to the modem. We found if we ran the main feed right into the modem, everything was fine and the connection problem went away. If the feed came out of the drop amplifier, though (I have a EVO 1-9-U/U), all the problems came back. So eventually we ended up putting a splitter in before the amplifier and before the MoCA filter, and ran that into the modem. Success! The downstream power levels are now between 5.5 - 6.7 dBmV and the connection issues vanished.

Thanks again for the help!

forum icon

New to the Community?

Start Here