Packet loss is incredibly difficult to deal with so any level of frustration would certainly make sense. I'm glad to hear that it's being investigated, has a ticket been sent for the issue with visibility of impact in the area? Or was a technician scheduled?
Hoping that you'll get some answers soon!
Hop 1 has 100% packetloss
I have been having voice cut out issues on discord and the only real problem I can find is that my wired connection is having 100% packetloss to hop one (tested with pingplotter and winmtr
@Fardin2000 you can't trust Pingplotter if you're using a white CODA-4582 modem, and possibly other Hitron modems as well.
The CODA-4582 and Pingplotter don't play well together and as a result, Pingplotter can and will show false packet loss from the modem or the next hop, depending on your ping target. This is due to a firmware change that occurred several versions ago. The packet loss indications do not appear to affect any IP address displayed beyond hop #2. This problem was fixed a very long time ago for the CGN3ASMR or CGNM-3552, but, I'm not aware of the current situation with those modems and Pingplotter.
1. If you ping the modem address only, the bottom plot will show the latency plot of that single IP address. You shouldn't have packet loss to the modem, unless you have a local network problem via ethernet, or, if you're running the pingtest via wifi, which you shouldn't be doing for the purposes of testing beyond the modem. Running Pingplotter via wifi, pinging the modem via wifi would actually be a good demonstration of how poor wifi can be at times. So, keep in mind, you shouldn't see any packet loss at this point. If you do, run a command line ping test to confirm or deny the presence of any packet loss.
2. If you ping the address beyond the modem which is the CMTS, Pingplotter will show a high loss from the modem and no loss from the CMTS. Keep in mind that you just confirmed that there is no packet loss to/from the modem, so Pingplotter is generating a false packet loss indication in this case.
3. If you ping a target beyond the CMTS (hop #2), such as the Rogers primary IPV4 DNS @ 220.127.116.11, you will see high packet loss from the modem and from the CMTS, but, you just proved to yourself that there is no packet loss from either one. Once again, Pingplotter is generating a false packet loss indication from the modem and CMTS. You shouldn't see any packet loss from the DNS address.
Keep in mind that Pingplotter displays the last IP address on the plot. So, if you ping some far off target, the local plots aren't seen unless you click or select any of the IP addresses in the IP trace. That will bring up the plot for that IP and they will stack vertically. Right click on any plot and select "hide" to get rid of any unwanted plot.
Pingplotter generates a considerable amount of traffic, blasting each IP address with two pings per cycle, so, the program generates a far more traffic than users are aware of. For that reason, when it comes to checking for packet loss and latency, I highly recommend doing it in the following order in order to minimize the traffic:
1. Ping the modem, 192.168.0.1
2. Ping the CMTS (second IP address in any trace to anywhere)
3. Ping the Rogers primary DNS, 18.104.22.168 (that keeps the test within the Rogers network)
4. Ping a target outside of the Rogers network. (only do this when you have completely resolved any issues
seen in steps 1, 2, and 3. When you run a ping test outside
of the ISP borders, all bets are off and you get what you
get, so you really need to know the performance within
the network first, before you start to tackle Rogers about
any problems beyond the ISP border.)
When Pingplotter is running, right click on the column title bar to bring up the title bar menu. Select MAX and ERR. Drag those columns to the right to sit beside the MIN and % columns.
With long time frame plots, or with high rate data which occurs when you override the default Ping intervals and drop the intervals below 0.5 (seconds), you will end up with more data per horizontal pixel than can actually be displayed. Pingplotter stacks a number of horizontal pixel data points together, and when that happens Pingplotter averages the horizontal pixel data points in the plot, so, as you scale up in time, the plot flattens out, losing the high time latency spikes. That makes Pingplotter fairly useless in monitoring latency issues over long time periods. if you hover your mouse over the lower plot area, it will show the number of data points in that particular horizontal pixel point. With the upper right hand Focus time set to Auto to match up the top data timeframe with the lower timeframe, the MAX column will show the maximum latency time within that time frame. Unfortunately, you might not be able to determine where that occurs unless you scale the plot way down in time and laboriously scroll thru the plot, looking for the latency spikes.
Ok, for now, I suggest re-configuring the test to run single tests, first to the modem, and then to the CMTS, looking for packet loss and latency.
Packet loss within the Rogers network causing high loaded latency
I've been having ongoing issues with my internet. I'm having very high "loaded latency" from my gateway to the internet. This causes disconnects to my VOIP and screen sharing applications and response times from constantly connected applications. I've been doing speed tests on fast.com and using Ping Plotter to check for packet loss upstream.
I've been in touch with Rogers support several times and they were unable to fix the issue. They "escalated" the issues last week and responded back by text that they were unable to find an issue. Here's what I've done so far to troubleshoot.
1. Cable tech came out and replaced all lines from the street to the house and from house inside to the modem. All check out good now.
2. Replaced cable modem (CODA-4582U)
3. I had the modem firmware updated to latest version (on last modem, new modem (same model) does not have updated firmware yet)
4. Tested from a separate laptop direct to the modem with a different network cable.
5. Removed all other networking equipment from my network.
6. Set my modem to "bridge" mode and installed a 3rd party Linksys router to test if packet loss and latency persisted. It did, same results. Right now I'm running with the Rogers modem as my Gateway again.
I'm on a 300u package, here's my results from fast.com:
300 - 600mbps download, 20mbps upload - Sometimes get only 150mbps download during peak periods.
13ms latency on average
250 - 650ms loaded latency (changes intermittently throughout the day, a few times I did get 60ms loaded latency but that was short lived and few and far between)
I'm consistently receiving 35% packet loss on average within the Rogers network. Specifically to the first hop outside my gateway. This packet loss occurs every day, evening and night - all the time for months.
Hop with packet loss: 22.214.171.124
Here's my Ping Plotter results for reference of the packet loss, in this example I received 37% loss:
Target Name: google.ca
Date/Time: 10/15/2019 07:39:55 - 10/15/2019 07:49:55
Hop Sent PL% Min Max Avg Host Name / [IP]
1 1190 100 1.32 1.32 1.32 CODA4582 [192.168.0.1]
2 1190 37 8.74 97.89 15.50 cpe.net.cable.rogers.com [126.96.36.199] (redacted CM MAC address - RogersMoin)
3 1190 0 8.00 30.95 11.33 8081-dgw02.ktgc.rmgt.net.rogers.com [188.8.131.52]
4 1190 0 8.79 37.33 14.86 184.108.40.206 [220.127.116.11]
5 1190 0 8.58 105.13 15.87 18.104.22.168 [22.214.171.124]
6 1190 0 8.75 189.01 16.29 126.96.36.199 [188.8.131.52]
7 1190 0 11.34 50.13 15.85 184.108.40.206 [220.127.116.11]
8 1190 0 7.82 38.11 15.83 18.104.22.168 [22.214.171.124]
9 1190 0 9.08 33.28 14.76 google.ca [126.96.36.199]
I've done all I can to troubleshoot from what I can think of. Not sure how to get Rogers to see the problem as their "escalation" service is saying they don't see a problem and won't speak with me directly. Hoping someone can assist.
Packet Loss Impossible to Play
Hi, I am Rogers new client and I have been suffering several packet loss most of the time when I was playing. I am trying to play BattleField V and It was impossible to play, even wired. My Modem is as CODA-4582U.
@CristianBotelho can you delete the two images as their IPV6 addresses, specifically your's shouldn't be posted in an open forum unless you delete or obfuscate the actual addresses themselves. The first hop identifies your modem address, don't want to see this posted in an open forum. Doing this with an IPV4 address isn't a problem.
Ok, so to make a long story short, pingplotter and the 4582 don't play well together, so you can end up with false packet loss indications from Hop #1 and #2.
To get around this you have to run separate tests, first to the modem which is Hop #1. The purpose here is to ensure that you don't have an internal cabling issue when your running via ethernet. This type of testing should always be done via ethernet, although, running a ping test to the modem or router via wifi can be a good demonstration to the end user of just how bad wifi can actually be.
So, assuming that you have 188.8.131.52 as your normal modem address, ping that address. If you've changed the modem's internal address to something else, ping that address. Since you can ping the modem at high rates, go ahead and do that. Drop the ping interval by overwriting the indicated ping interval. Drop that down to something like 0.01 (seconds) or lower if you're interested in experimenting. You won't break the modem. When the ping test is running, right click on the title bar of the columns to display the column menu. Select MAX and ERR. When their displayed, drag them to the right to sit beside the Min and PL% columns.
When that is running and the data fills the lower plot area, you will probably get to a point where there is too much data to display, and as a result, Pingplotter averages the plot data without warning the user. The MAX data in the text data will display the Maximum latency observed even if the lower plot data is averaged. If you leave the mouse in the lower plot area, or move it left and right very slowly, you will see how many data points are plotted in each pixel point. Ok, so as I indicated above, the purpose here is to look for packet loss to and from the modem. There shouldn't be any packet loss in your internal network. If there is, you have some homework to do to determine where the problem lies.
Next step is to look for packet loss to Hop #2. Enter the following address in the address bar: ipv4:www.google.com
Let that run for a few seconds. Copy the IP address for Hop #2. That is the Cable Modem Termination System (CMTS) which provides data to, and control over the modem operations. The actual path is:
1. Modem to house demarcation point (outside of the house).
2. Demarcation point to local tap (either housed in a pedestal for underground cabling or on a utility pole for overhead cabling.
3. Local tap to neighbourhood node.
4. Neighbourhood node to CMTS.
Typically, if there is a packet loss problem, that will occur in leg #2 above. As the external cable and its connectors age, its typical to see water ingress, which grounds out the internal copper conductor. This will usually get worse over time, and be a source of a lot of frustration until the cable is eventually replaced.
There is also a possibility that the problem itself is at the local tap, which connects you and your immediate neighbours, or possibly the problem is further upstream on leg #3.
So, paste or type the Hop #2 address into the address bar and run that at 0.1 (seconds) for the interval. The same situation applies here for averaged data in the lower plot area. As you increase the lower plot time from 60 seconds, to 10 min to 48 hours, etc, you end up with more data in the specified time frame. Thats where Pingplotter will average the plot times for every horizontal pixel.
In this test, you will see packet loss from the modem. That's due to the modem's internal timing. Don't be surprised, but, you've just proven to yourself that the modem itself is free of any packet loss, or so I'm assuming. You will see high latency times in this test to the CMTS. Don't be surprised by this. Once again, its due to the modem's processing and internal timing. What you're looking for in this case is any packet loss that occurs enroute to the CMTS and back again. Just about the only thing that Pingplotter is useful for, personal opinion, is indicating where packet loss occurs.
Ok, so, let that run and post the two plots, the first being the modem ping test, the second being the CMTS ping test.
If you run a ping test to some target beyond Hop #2, you will see packet loss from the modem and CMTS, but, once again, you probably just proved that there is no packet loss from either one, so, as usual, this is a false packet loss indication. For any target that gives you a packet loss indication, if you want to confirm that the packet loss is correct, you can run a command line ping to that same target. That will confirm or disprove the packet loss indicated by Pingplotter.
Your next ping target should be the Rogers DNS 184.108.40.206 That will run the ping test beyond the CMTS, but, keep the ping test within the Rogers network. You will see packet loss from the modem and CMTS (where there is none), but, the test purpose at this point is to look for packet loss within the network, beyond the CMTS. When and only when you have proven to yourself that a problem exists or doesn't exist with the network, should you consider going outside of the network, to some far off target. Hopefully you would know that there isn't an issue within the Rogers network. That puts the blame on the border servers or beyond. That's a tougher nut to crack, if that turns out to be the case.
Can you also log into the modem and navigate to the STATUS .... DOCSIS WAN tab. Copy the entire signal level table, from the Downstream Overview line, all the way to the bottom right hand corner of the bottom OFDM/OFDMA section. Select or highlight that entire table, right click .... Copy. Then in a new post, right click ..... Paste. That table should paste into the post and look like the original table as its displayed in the modem. Ignore the data that sits above the Downstream Overview as its specific to the modem and shouldn't be posted. Maybe the signal level table itself will indicate if there's a signal issue afoot.
@Datalink follow the docsiswan table.
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
@CristianBotelho can you post the rest of the signal table please. That will include the OFDM Downstream Overview, Upstream Overview, OFDM/OFDMA Overview. Can you also confirm which firmware version is loaded on your modem. That is shown on the STATUS page when you log into the modem. Its listed as the Software version. At the present time you should have version 220.127.116.11T6 loaded.
Looking at the DOCSIS 3.0 channels that you posted, in terms of the signal levels themselves, I wouldn't expect you to see any issues with those levels. The signal to noise ratios are borderline. They should be in the 36 to 40 dB range, where yours are just under 36 dB. So, there is some level of noise on your cable line, just enough to drop the signal to noise ratios slightly. Now, given that your running a 4582 modem, these DOCSIS 3.0 channels aren't used as the modem should be running DOCSIS 3.1 on the downstream side, so there should be one OFDM channel that is active. The OFDM data should confirm that.
You definitely have some packet loss out and back from the CMTS. I'd like to see a much longer test run in both cases. At least an hour or longer.
Can you confirm your network layout for me? Are you connecting directly to the modem with a reasonably short ethernet cable, or running through any switches or house ethernet cabling?
The plot for the DNS ping test isn't publicly available as of yet as it hasn't been approved by one of the moderators at this point in time. It should be available soon.