I have been having intermittency that got increasingly worse for around a year now. After multiple calls to Rogers and having technicians come over to try and diagnose the issue, they weren't able to find the reason. However, about a week ago, after relocating my modem, I realized that rebooting it stopped the intermittency completely for a day, and then the next day it would be the same. I came across another forum which explained another person's situation which seemed identical to mine, but worse, and the issue was a "plant issue". Is there anyway to see if this issue applies to me, as well as how I would go about explaining it? Or if not, another solution if someone had this same problem?
@Redfish, and you've been in the house for how many years now?
Looking at your signal levels, they're not too bad. The downstream DOCSIS 3.0 channels (1-32) are a little high but not by a huge amount. I'd like to see them closer to 0 dBmV, but, where they are shouldn't be an issue. The target across the board is 0 dBmV, with 256 QAM and a signal to noise ratio of 36 to 40 dB. So, overall, your downstream signal levels aren't bad at all.
Now, fwiw, the modem is using the DOCSIS 3.1 OFDM channel for its downstream data. That can be seen by the active OFDM channel. There isn't enough data presented to determine the health of the OFDM channel, so you would have to call tech support and ask a customer service rep if the OFDM channel numbers are ok. They include the signal level, signal to noise ratio and QAM number, which should be at 1024 for this modem running in a low noise environment.
The upstream levels are a little elevated, but, I don't know which splitter port your modem is connected to. Typically with this modem those upstream channels run in the 30 to 32 dBmV range. if the modem is connected to a -7.5 dB port, then the normal numbers would be in the 31 to 33.5 range which isn't bad at all. If the modem is on the -3.5 dB port, then those channels are running in a 35 to 37.5 dBmV range which still isn't too bad.
Ok, so, despite fairly decent numbers, you can still run into issues if the cable has aged to the point where its cracking and letting water into the center copper conductor. That usually results in fast disconnects and reconnects which happen too fast for the signal table to catch. The DOCSIS events log might just show the results of those disconnects. Tech support should have access to a log that shows the modem disconnects, and should be able to tell you if the number of disconnects is normal or if the number that is shown is larger than normal.
The next step is to look for packet loss due to the disconnects. You can do this with a normal ping command, or download and run pingplotter which will run for 14 days in a freebie ping mode. As much as I loath recommending Pingplotter due to its data compression that makes any latency look better than it is, its a useful tool to use to look for packet loss. Normally, when you get a fast disconnect/reconnect, you will end up with packet loss. Running a local ping test is an easy way to check for that packet loss.
To do that, run a command trace to anywhere, google for example:
tracert -4 www.google.ca
The first hop IP address will be the modem (stand alone), or a follow on router if the modem is running in Bridge mode with a router behind it.
The second hop IP address will be the Cable Modem Termination System (CMTS) which provides modem control and modem data services.
Ignore everything after Hop #2. Ping the second hop IP address: ping xxx.xxx.xxx.xxx
The actual path is:
1. pc to modem via ethernet:
2. modem to local tap (on utility pole) which connects you and your immediate neighbours;
3. Local tap neighbourhood node;
4. Neighbourhood node to CMTS
So, assuming that your ethernet and internal cabling are ok, that leaves the external cable to the utility pole and cabling from there to the neighbourhood node. The run from the neighbourhood node to the CMTS will be fibre. What you're testing in this case is the cabling to the utility pole and out to the neighbourhood node, with the cabling out to the utility pole being the usual culprit.
Let that ping test run for a considerable amount of time. You can use Ctrl+ C to bail out of the test. Fwie, I run high rate ping tests for latency test purposes, usually 24 hour periods. I'm assuming that you're on an unlimited plan, so running a command line ping which only pings once per second won't be an issue. If you wanted to run a high rate ping test you can use HrPing from: www.cfos.de
Thats a command line program that allows the user to run high rate ping tests. In either case, with the Windows ping command or HrPing, you should only end up with a handful of lost packets, usually below 1%. If you get to 1% or higher, then there's a problem somewhere in the cabling.
And, if you wanted to see the results visually, you can run Pingplotter in Pro mode for 14 days before it kicks down into a basic mode, unless of course you buy a pro or standard licence. The standard licence is fine for the purpose of looking for packet loss. This is just about the only use that I would recommend Pingplotter for, as it presents an easy to understand picture of any packet losses.
Ok, that should do it for now.
Thanks a lot for the help. I have been in this house for 2 years now. I have ran the traceroute and the IP address I ping is the one after the modem's (192.168.0.1)? If so, I have started pinging that IP using PingPlotter with the free license, as HrPing wouldn't open for me after its initial launch.
For some reason, large packet loss is coming from the ping to my modem? I'm not entirely sure how this works, but I have tried to use cmd and ping my modem, which from there I get 1ms or less every ping.
I'm glad to see your following directions listed from @Datalink! These steps can certainly go a long way to identifying packet loss. I for one am no stranger to how difficult it can be to identify, source and resolve it so I appreciate your patience through all of this testing.
Are you able to provide the results of your traceroute and ping tests? This will allow us to see what you're seeing. From there we can determine next steps for you to get a full resolution. Be sure to remove any personal information if visible.
In addition, when logging into your modem, on the Status page you'll see at the bottom a LAN uptime and WAN uptime value. If you haven't manually rebooted your modem since the last disconnect can you share those values with us? Thanks!
Thanks a lot for your response! So I have attached the status page of my modem, as well as whatever I could show off Pingplotter which was pinging the local tap neighbourhood node, or the second hop address off a traceroute to Google.
***edited for privacy***
This chart goes as: avg/min/cur/PL% and i'm not sure what the picture represents.
I just ran PingPlotter for around 10 min, however this is what it normally looks like.
As for the traceroute, I'm not quite sure how to show it without showing personal information, which is the main part, while the other hops are what everyone else uses to access that site? Thanks for the help.