Visitor
•
5 Messages
Packet loss on 16/3 service
I am seeing packet loss and bursts of high ping times from my 16/3 basic business internet service to multiple sites on the internet (google.com, systems at ANL). I also see this behavior pinging the next hop after the local router.
Equipment is Arris CM820A. All cable connections I can see are intact and tight, no splitters involved. Modem has been power cycled.
Details as requested in the troubleshooting tips follows. Thanks for any assistance.
--bob
Normal network topology has a cerowrt router attached to the modem; I am still seeing the packet loss with a mac laptop attached directly to the modem.
Speedtest (through my router again via hardwired gigabit ethernet) shows 30ms ping, 18.85 down, 3.55 up.
System: | ARRIS DOCSIS 3.0 Touchstone WideBand Cable Modem HW_REV: 1 VENDOR: Arris Interactive, L.L.C. BOOTR: 1.2.1.52 SW_REV: 9.1.93 MODEL: CM820A |
Serial Number: | C7LBRL465105075 |
Options: |
Firmware Build and Revisions |
Firmware Name: | TS090193_061815_WBM760_CM820 |
Firmware Build Time: | Thu Jun 18 05:09:46 EDT 2015 |
Downstream
DCID | Freq | Power | SNR | Modulation | Octets | Correcteds | Uncorrectables | |
Downstream 1 | 9 | 705.00 MHz | 4.45 dBmV | 38.26 dB | 256QAM | 15583017 | 0 | 0 |
Downstream 2 | 10 | 711.00 MHz | 4.30 dBmV | 38.98 dB | 256QAM | 13279317 | 0 | 0 |
Downstream 3 | 11 | 717.00 MHz | 4.32 dBmV | 38.61 dB | 256QAM | 10504760 | 0 | 0 |
Downstream 4 | 12 | 723.00 MHz | 4.11 dBmV | 38.26 dB | 256QAM | 13932865 | 0 | 0 |
Downstream 5 | 13 | 729.00 MHz | 4.15 dBmV | 39.40 dB | 256QAM | 18995745 | 0 | 0 |
Downstream 6 | 14 | 735.00 MHz | 4.17 dBmV | 38.98 dB | 256QAM | 5084097 | 0 | 0 |
Downstream 7 | 15 | 741.00 MHz | 4.32 dBmV | 39.40 dB | 256QAM | 6121101 | 0 | 0 |
Downstream 8 | 16 | 747.00 MHz | 4.43 dBmV | 38.98 dB | 256QAM | 8753467 | 0 | 0 |
Reset FEC Counters |
Upstream
UCID | Freq | Power | Channel Type | Symbol Rate | Modulation | |
Upstream 1 | 10 | 29.50 MHz | 43.75 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Upstream 2 | 11 | 22.60 MHz | 42.75 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Upstream 3 | 9 | 36.40 MHz | 44.50 dBmV | DOCSIS2.0 (ATDMA) | 5120 kSym/s | 64QAM |
Ping stats to google.com when directly attached to modem:
$ ping google.com
PING google.com (216.58.216.238): 56 data bytes
64 bytes from 216.58.216.238: icmp_seq=0 ttl=56 time=11.651 ms
64 bytes from 216.58.216.238: icmp_seq=1 ttl=56 time=12.089 ms
64 bytes from 216.58.216.238: icmp_seq=2 ttl=56 time=12.078 ms
64 bytes from 216.58.216.238: icmp_seq=3 ttl=56 time=12.431 ms
64 bytes from 216.58.216.238: icmp_seq=4 ttl=56 time=11.811 ms
64 bytes from 216.58.216.238: icmp_seq=5 ttl=56 time=12.304 ms
64 bytes from 216.58.216.238: icmp_seq=6 ttl=56 time=12.785 ms
64 bytes from 216.58.216.238: icmp_seq=7 ttl=56 time=11.952 ms
64 bytes from 216.58.216.238: icmp_seq=8 ttl=56 time=12.686 ms
64 bytes from 216.58.216.238: icmp_seq=9 ttl=56 time=24.092 ms
64 bytes from 216.58.216.238: icmp_seq=10 ttl=56 time=11.416 ms
64 bytes from 216.58.216.238: icmp_seq=11 ttl=56 time=27.478 ms
Request timeout for icmp_seq 12
64 bytes from 216.58.216.238: icmp_seq=13 ttl=56 time=11.778 ms
64 bytes from 216.58.216.238: icmp_seq=14 ttl=56 time=12.077 ms
64 bytes from 216.58.216.238: icmp_seq=15 ttl=56 time=11.898 ms
64 bytes from 216.58.216.238: icmp_seq=16 ttl=56 time=12.969 ms
64 bytes from 216.58.216.238: icmp_seq=17 ttl=56 time=12.644 ms
64 bytes from 216.58.216.238: icmp_seq=18 ttl=56 time=12.204 ms
64 bytes from 216.58.216.238: icmp_seq=19 ttl=56 time=12.106 ms
64 bytes from 216.58.216.238: icmp_seq=20 ttl=56 time=11.479 ms
64 bytes from 216.58.216.238: icmp_seq=21 ttl=56 time=25.159 ms
64 bytes from 216.58.216.238: icmp_seq=22 ttl=56 time=12.436 ms
64 bytes from 216.58.216.238: icmp_seq=23 ttl=56 time=12.216 ms
64 bytes from 216.58.216.238: icmp_seq=24 ttl=56 time=12.098 ms
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
64 bytes from 216.58.216.238: icmp_seq=27 ttl=56 time=22.127 ms
64 bytes from 216.58.216.238: icmp_seq=28 ttl=56 time=12.538 ms
Request timeout for icmp_seq 29
64 bytes from 216.58.216.238: icmp_seq=30 ttl=56 time=22.080 ms
Request timeout for icmp_seq 31
Request timeout for icmp_seq 32
64 bytes from 216.58.216.238: icmp_seq=33 ttl=56 time=12.032 ms
64 bytes from 216.58.216.238: icmp_seq=34 ttl=56 time=37.292 ms
64 bytes from 216.58.216.238: icmp_seq=35 ttl=56 time=21.749 ms
64 bytes from 216.58.216.238: icmp_seq=36 ttl=56 time=12.639 ms
64 bytes from 216.58.216.238: icmp_seq=37 ttl=56 time=12.087 ms
Request timeout for icmp_seq 38
64 bytes from 216.58.216.238: icmp_seq=39 ttl=56 time=22.494 ms
64 bytes from 216.58.216.238: icmp_seq=40 ttl=56 time=12.754 ms
64 bytes from 216.58.216.238: icmp_seq=41 ttl=56 time=12.014 ms
Request timeout for icmp_seq 42
64 bytes from 216.58.216.238: icmp_seq=43 ttl=56 time=11.850 ms
64 bytes from 216.58.216.238: icmp_seq=44 ttl=56 time=11.980 ms
64 bytes from 216.58.216.238: icmp_seq=45 ttl=56 time=12.426 ms
^C
--- google.com ping statistics ---
46 packets transmitted, 38 packets received, 17.4% packet loss
round-trip min/avg/max/stddev = 11.416/14.945/37.292/5.812 ms
rdo
Visitor
•
5 Messages
9 years ago
I was seeing stutters and hangs on interactive ssh sessions. I also saw occasional hangs on page loading in web browsers. The packet loss and delay in ping traffic appears to correlate.
0
0
xz4gb8
Problem solver
•
117 Messages
9 years ago
rdo,
It is helpful to understand that processing of an ICMP echo (ping) request is a low priority activity for most systems. This is in contrast to actual connection data traffic, the highest priority.
1. A Request timeout response most likely indicates the target system was busy doing its primary task, handling user data, not pings.
2. The result for pinging the next hop after the local router (also a router) follows the same logic - a router's primary purpose is forwarding packets. Ping responses can easily be delayed or even time out because the router is doing its job.
Bottom Line: What problem are you having that prompts you to use ping?
0
0
kraze
Problem solver
•
305 Messages
9 years ago
I'd recommend running an MTR to a few sites and posting those results here. If you're able to try running one to a service where you can get an outbound MTR as well as this can help us get the full picture.
0
0
rdo
Visitor
•
5 Messages
9 years ago
mtr looking really good right now though. Definitely better than when I was seeing trouble.
0
0
rdo
Visitor
•
5 Messages
9 years ago
I'll try to catch one. I did run a couple while I was having the problems and saw a lot of packet losses, but large enough numbers to make me doubt what was going on. I do have my pingtime monitors running again though. Overall things have improved since the other day so I suspect the problem may not have been local to me; or perhaps it was at a neighborhood level (would love to know IP of another comcast customer on this side of the routing infrastructure. I don't know enough about the architetural details of the comcast last-mile network to know if there's a L2 segment behind the first hop router where it'd make sense to do local monitoring).
Local network is in good shape. ping to local router.
Pings times to various sites show correlated spikes.
0
0
rdo
Visitor
•
5 Messages
9 years ago
Interesting. Checked the monitors today and still no loss, but the traceroute path length to ANL and the ping times both jumped. Traffic going thru NY now (from chicago suburb to another chicago suburb about 15 miles away).
0
0