04-07-2019 08:14 PM - last edited on 04-07-2019 08:37 PM by RogersTim
Hi all, I've been researching this problem for the last few weeks, and notice many people have similar issues. I have a tech come over a week from now, and want to make sure I ask all the right questions and have him/her check everything they should.
My internet has been intermittent since I moved to Brantford, ON in August 2018. Have had my Hitron replaced 3 times. So I highly doubt it's the modem. My LAN has also been up constantly, but my WAN drops a significant amount per day for about 20-30sec (as many as 15 times a day).
Here is my data. If anyone could help me prepare for when the tech comes, that would be great!!
1 | 04/07/2019 10:37:19 | 82000300 | critical |
Ranging Request Retries exhausted
|
2 | 04/07/2019 10:37:19 | 82000600 | critical | Unicast Maintenance Ranging attempted - No response - Retries exhausted; |
etc
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 633000000 | 256QAM | -0.700 | 13 | 36.387 |
2 | 849000000 | 256QAM | 1.000 | 2 | 35.780 |
3 | 855000000 | 256QAM | 1.200 | 3 | 35.595 |
4 | 861000000 | 256QAM | 1.000 | 4 | 35.595 |
5 | 579000000 | 256QAM | -1.200 | 5 | 36.387 |
6 | 585000000 | 256QAM | -1.100 | 6 | 35.780 |
7 | 591000000 | 256QAM | -1.100 | 7 | 35.780 |
8 | 597000000 | 256QAM | -1.100 | 8 | 35.780 |
9 | 603000000 | 256QAM | -0.900 | 9 | 35.780 |
10 | 609000000 | 256QAM | -0.600 | 10 | 36.387 |
11 | 615000000 | 256QAM | -0.600 | 11 | 36.610 |
12 | 621000000 | 256QAM | -0.600 | 12 | 36.610 |
13 | 303000000 | 256QAM | -3.500 | 1 | 37.636 |
14 | 639000000 | 256QAM | -0.600 | 14 | 36.387 |
15 | 645000000 | 256QAM | 0.000 | 15 | 36.387 |
16 | 651000000 | 256QAM | 0.300 | 16 | 37.356 |
17 | 657000000 | 256QAM | 0.200 | 17 | 36.610 |
18 | 663000000 | 256QAM | 0.300 | 18 | 36.610 |
19 | 669000000 | 256QAM | 0.300 | 19 | 36.610 |
20 | 675000000 | 256QAM | 0.300 | 20 | 36.387 |
21 | 681000000 | 256QAM | 0.200 | 21 | 36.610 |
22 | 687000000 | 256QAM | 0.300 | 22 | 36.610 |
23 | 693000000 | 256QAM | 0.200 | 23 | 36.610 |
24 | 699000000 | 256QAM | 0.300 | 24 | 36.387 |
25 | 705000000 | 256QAM | -0.300 | 25 | 36.610 |
26 | 711000000 | 256QAM | -0.300 | 26 | 36.387 |
27 | 717000000 | 256QAM | -0.300 | 27 | 36.387 |
28 | 723000000 | 256QAM | -0.400 | 28 | 35.780 |
29 | 825000000 | 256QAM | 1.900 | 29 | 36.610 |
30 | 831000000 | 256QAM | 1.600 | 30 | 36.387 |
31 | 837000000 | 256QAM | 1.200 | 31 | 35.595 |
32 | 843000000 | 256QAM | 1.000 | 32 | 35.780 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | NA | NA | NO | NO | NO | NA |
1 | 4K | 275600000 | YES | YES | YES | -1.700001 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 30596000 | ATDMA - 64QAM | 38.500 | 1 | 6400000 |
2 | 38595824 | ATDMA - 64QAM | 43.250 | 3 | 3200000 |
3 | 23700000 | ATDMA - 64QAM | 38.500 | 2 | 6400000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
1 | DISABLED | 0.5000 | 0.0000 | 0.0000 | -inf | -1.0000 | 4K |
04-07-2019 08:33 PM - edited 04-07-2019 08:34 PM
This is how the cable enters the house. The old wire is connected to a wire that has been added in August.
I think it would be better to have a wire without any connectors straight into the outside green box correct?
This is the old wire:
04-08-2019 05:29 PM
Would any expert on this forum need more information from me in order to provide an answer? please let me know if you do! 🙂
04-08-2019 08:40 PM
Hey @Lodar,
Thank you for your detailed post! 🙂
That is a lot of disconnects, so I would be looking for help as well. Your signal looks good and I agree it probably isn't your modem since you've replaced it a few times already. We do sometimes replace sections of your coaxial cable and use connectors like the one in your picture. We may need to replace the line depending on the state it is in.
I think it might be best to wait for the technician you have coming next week so they can track down the intermittency.
Perhaps, our Resident Expert @Datalink can give you a few pointers! 🙂
RogersTim
08-28-2019 09:42 PM - last edited on 08-28-2019 10:26 PM by RogersMaude
Ranging Response errors, constant internet drops
Honestly I'm not sure what can be done about this because my understanding is it's most likely infrastructure, but here's hoping it's not.
For the past few weeks I've been having regular disconnects for no apparent reason. My Coda 4582U gives me errors about a ranging response and will only reconnect when I reboot, ever. I'm not unfamiliar with this issue, I've been having this problem at a variety of other houses over several years. But with regards to the issue now, what options do I have for fixing this? Is there any clue that a tech could look at here to fix this?
Downstream Overview | |||||||
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) | ||
1 | 591000000 | 256QAM | 2.5 | 7 | 38.605 | ||
2 | 849000000 | 256QAM | -4.4 | 2 | 36.387 | ||
3 | 855000000 | 256QAM | -4.2 | 3 | 36.387 | ||
4 | 861000000 | 256QAM | -2.7 | 4 | 37.356 | ||
5 | 579000000 | 256QAM | 2.4 | 5 | 38.983 | ||
6 | 585000000 | 256QAM | 2.3 | 6 | 38.983 | ||
7 | 279000000 | 256QAM | 5.4 | 1 | 38.983 | ||
8 | 597000000 | 256QAM | 2.3 | 8 | 38.605 | ||
9 | 603000000 | 256QAM | 2.6 | 9 | 38.983 | ||
10 | 609000000 | 256QAM | 3.2 | 10 | 38.983 | ||
11 | 615000000 | 256QAM | 2.7 | 11 | 38.605 | ||
12 | 621000000 | 256QAM | 2.9 | 12 | 38.605 | ||
13 | 633000000 | 256QAM | 2.9 | 13 | 38.983 | ||
14 | 639000000 | 256QAM | 2.8 | 14 | 38.605 | ||
15 | 645000000 | 256QAM | 3.2 | 15 | 38.983 | ||
16 | 651000000 | 256QAM | 3.3 | 16 | 38.605 | ||
17 | 657000000 | 256QAM | 3.4 | 17 | 38.605 | ||
18 | 663000000 | 256QAM | 3.8 | 18 | 38.605 | ||
19 | 669000000 | 256QAM | 4.5 | 19 | 38.605 | ||
20 | 675000000 | 256QAM | 5.1 | 20 | 40.366 | ||
21 | 681000000 | 256QAM | 4.8 | 21 | 40.366 | ||
22 | 687000000 | 256QAM | 4.3 | 22 | 38.983 | ||
23 | 693000000 | 256QAM | 4.3 | 23 | 38.983 | ||
24 | 699000000 | 256QAM | 3.8 | 24 | 38.983 | ||
25 | 705000000 | 256QAM | 3.6 | 25 | 38.983 | ||
26 | 711000000 | 256QAM | 3.2 | 26 | 38.983 | ||
27 | 717000000 | 256QAM | 3.4 | 27 | 38.605 | ||
28 | 723000000 | 256QAM | 3.3 | 28 | 38.983 | ||
29 | 825000000 | 256QAM | -3.3 | 29 | 36.61 | ||
30 | 831000000 | 256QAM | -3.4 | 30 | 36.61 | ||
31 | 837000000 | 256QAM | -3.2 | 31 | 36.61 | ||
32 | 843000000 | 256QAM | -4.4 | 32 | 36.387 | ||
OFDM Downstream Overview | |||||||
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) | |
0 | NA | NA | NO | NO | NO | NA | |
1 | 4K | 275600000 | YES | YES | YES | 4.199997 | |
Upstream Overview | |||||||
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth | ||
1 | 23700000 | ATDMA - 64QAM | 36.25 | 5 | 6400000 | ||
2 | 38596000 | ATDMA - 64QAM | 39.75 | 6 | 3200000 | ||
3 | 30596000 | ATDMA - 64QAM | 36.25 | 4 | 6400000 | ||
OFDM/OFDMA Overview | |||||||
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.5 | 0 | 0 | -inf | -1 | 4K |
1 | DISABLED | 0.5 | 0 | 0 | -inf | -1 | 4K |
08-29-2019 09:05 PM
Hey @Tempystral!
Intermittency can be incredibly tedious to troubleshoot on your own for sure. I'm glad you're reaching out here!
Based on the signals provided there's no RF level issue there. Are you able to provide the WAN and LAN uptime from the Status page in your modem? If you can do so after you experience a disconnect that would be optimal. Be sure not to manually reboot the modem before grabbing that snapshot.
This can effectively be the smoking gun that a technician can investigate for you. If there's nothing from within the home causing the concern then maintenance can check for shorts occurring along the line which could also contribute to this intermittency.
@RogersAndy
08-30-2019 12:20 PM
08-31-2019 01:24 AM
08-31-2019 03:33 AM
Hi there,
I found your post because I've been experiencing the same disconnection issues lately. While away for 3 weeks, my home security became off-line so when I got back, I found out that my internet connection goes down and I have to reboot it several times to get it back online. Then after accessing the Hitron router pages, I Googled one of the critical errors on the log and that's how I found this forum topic.
I may have to call this in this weekend.
08-31-2019 10:02 PM
Hey @Tempystral,
Thanks so much! seeing approximately 2 minutes difference in LAN/WAN uptime is normal after a reboot as that will account for the modem ranging. If there's a difference that exceeds that though that would indicate a loss of internet connection to the modem likely due to some level of RF issue. If you're losing connection on your devices and the WAN uptime is consistent, then the disconnect is likely home network related but keep us posted during the next disconnect if the WAN uptime is at a variance indicating a drop.
09-01-2019 12:39 AM
10-31-2019 07:03 PM
I have exactly the same problem but just found out that my phone modem also reboots the same time as Internet Modem. Anybody having Rogers phone and Internet please check your phone modem when you getting Internet Modem rebooting.
08-04-2020 08:22 PM - last edited on 08-04-2020 08:36 PM by RogersMaude
The DOCSIS event logs are shown here
No. | Time | Type | Priority | Event |
1 | 08/03/2020 14:37:14 | 74010100 | Notice | CM-STATUS message sent. Event Type Code: 5; Chan ID: 2; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;VER=3.1; |
2 | 08/03/2020 17:37:17 | 82000200 | Critical | No Ranging Response received - T3 time-out;VER=3.1; |
3 | 08/03/2020 22:02:54 | 82001200 | Warning | RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-VER=3.1; |
4 | 08/04/2020 02:34:10 | 66030111 | Alert | CM Certificate Error;VER=3.1; |
5 | 08/04/2020 02:46:22 | 90000000 | Warning | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;VER=3.1; |
6 | 08/04/2020 02:46:25 | 73050400 | Warning | REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-VER=3.1; |
7 | 08/04/2020 02:46:33 | 66030111 | Alert | CM Certificate Error;VER=3.1; |
8 | 08/04/2020 03:59:34 | 82000200 | Critical | No Ranging Response received - T3 time-out;CM-VER=3.1; |
9 | 08/04/2020 16:19:23 | 82001200 | Warning | RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-VER=3.1; |
10 | 08/04/2020 17:34:13 | 82000200 | Critical | No Ranging Response received - T3 time-out;CM-VER=3.1; |
11 | 08/04/2020 18:23:41 | 66030111 | Alert | CM Certificate Error;VER=3.1; |
12 | 08/04/2020 21:52:10 | 82001200 | Warning | RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;VER=3.1; |
13 | 08/05/2020 00:34:05 | 90000000 | Warning | MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-VER=3.1; |
14 | 08/05/2020 00:34:08 | 73050400 | Warning | REG-RSP-MP Mismatch Between Calculated Value for P1.6hi Compared to CCAP Provided Value;CM-VER=3.1; |
15 | 08/05/2020 00:34:16 | 66030111 | Alert | CM Certificate Error;CM-VER=3.1; |
08-05-2020 08:19 PM
Good evening @mohdkatlash,
Welcome to the Rogers Community and thanks you for your post! I hope you're doing well and staying safe. 🙂
We appreciate you took the time to share these findings with us regarding your internet service. Are you experiencing any issues with your service, at this time?
The ideal to do would be to describe us the symptoms that occur when you notice time-outs along with the troubleshooting steps you perform?
We definitely want to assist you with resolving this matter as soon as possible. Looking forward to your reply!
RogersMaude
08-05-2020 09:25 PM - edited 08-05-2020 09:26 PM
Hello
Thank you for your reply first, and same goes out to you.
And yes i am experiencing issues, the service seem to stops many time during the day as if the internet freeze and for troubleshooting steps mostly i just unplug the router for couple of minutes and plug it again. i am not an expert when it comes out to this thats why i was hoping to find a solution to this issue here
08-06-2020 09:25 PM
Thanks for posting the DOCSIS logs in the previous post @mohdkatlash.
Would you please log into the modem and navigate to Status/DOCSIS WAN and post the Downstream, Upstream and OFDM sections so that we can examine the signal levels?
Awaiting your reply.
RogersRob
08-08-2020 03:47 PM
I've also been experiencing these errors for a while with intermittent internet connection and latency issues.
The errors I get include the T3 timeouts, DHCP RENEW WARNING - Field invalid in response v4 option, CM certificate error, but also a new one that I haven't seen before, RNG-RSP CCAP Commanded Power in Excess of 6 dB below the Value Corresponding to the Top.
In my last discussion with support they weren't aware of the last RNG-RSP error or what it might indicate, is this something that might point to any issue? I can't find any explanation of what it might mean.
In the past few weeks we've also had issues with accessing our 192.168.0.1 page, which gets stuck in a loading loop and never loads, unless the modem is unplugged and then plugged back in, which gives us access to the page for about 24 hrs before it gets stuck in loading loops again.
We've been suggested to swap out our modem to see if it might be the issue, but we received an older CGN3 unit, and we have been using a CODA-4582, so I'm reluctant to go through the process of swapping it over at the moment. Just hoping to see if these error logs, particularly the newer RNG-RSP error might help pinpoint something before doing a bunch more work.
08-08-2020 04:24 PM
@RLMS there is a new firmware version, 7.1.1.32 that is loading on 4582 modems across the network. That version is responsible for the unusual alerts that you were seeing, and for the inability to log into the modem after a period of time. @RogersIan is aware of the access issues and loss of log events which are recovered after a modem reboot is done. Version 7.1.1.32 is built on a new kernel to support DOCSIS 3.1 upstream. The initial release was .30, .32 is loaded now, and one of these days the next version should show up. @RogersIan really needs to explain to the crowd what the event log errors mean and what to do about them.
That modem shouldn't be the cause of any disconnects. Having said that, the 4582 modem uses a DOCSIS 3.1 Orthogonal Frequency Division Multiplex (OFDM) channel for its downstream data which runs in the 300 to 500 Mhz range these days. There isn't enough data presented to the user to asses the health of that OFDM channel, so, it really requires a message to @CommunityHelps, specifically @RogersAndy to check the OFDM data in order to determine if a problem exists within the OFDM channel.
The CGN3 modems do not use an OFDM channel as they are not fitted with the hardware to use OFDM data transmission. The result of that is that the CGN3 modems use upstream DOCSIS 3.0 channels which run in the 5 to 42 Mhz range and DOCSIS 3.0 downstream channels in the 500 to 900 Mhz range, possible slightly higher.
So, because of the difference in frequency ranges used by the modems on the downstream side, you might not see any issues with the modem. That would or should confirm that your cable system has problems in the 300 to 500 Mhz range, for which there aren't enough data points with a CGN3 modem to make a proper assessment. That would require a field tech to check with the proper test equipment.
If you see the same intermittent internet connection and latency issues, that points to an issue with the upstream channels running in the 5 to 42 Mhz range. Latency could be a network issue which has been seen since January. Rogers has been and continues to be totally radio silent on the network problems that a good number of users, both Rogers and TPIA customers have seen.
Ok, so, fwiw, if you have the patience and time, log into the modem, navigate to the STATUS .... DOCSIS WAN tab and copy the Downstream and Upstream data, starting with the Downstream Overview line. Select or highlight that entire table region in one go, right click .... Copy. Then in a new post, right click .... Paste. That should paste in the table, as is seen in the modem's UI. Disregard the data that sits above the signal table, as that is specific to the modem and shouldn't be posted in an open forum.
Personal opinion, I'd go back to the 4582 in order to use the OFDM downstream channel. It should give you better performance on the downstream side. Now, that does depend on the health of that channel, which at this point is an unknown factor. One of these days Rogers will throw the switch and enable OFDM upstream. When is a good question.
08-08-2020 04:58 PM
Thanks so much for the in depth response! Ok good to know that is the cause of the new error, it was something I hadn’t seen in months of looking at the logs and the issue with not being able to access the modems login was new to me as well. Hopefully we can get some more info on that over time.
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Signal noise ratio (dB) |
1 | 651000000 | QAM256 | 3.000 | 16 | 40.946 |
2 | 591000000 | QAM256 | 2.000 | 7 | 40.366 |
3 | 597000000 | QAM256 | 2.599 | 8 | 40.366 |
4 | 849000000 | QAM256 | 5.500 | 2 | 40.366 |
5 | 855000000 | QAM256 | 5.900 | 3 | 40.946 |
6 | 861000000 | QAM256 | 5.699 | 4 | 40.366 |
7 | 579000000 | QAM256 | 1.799 | 5 | 40.366 |
8 | 585000000 | QAM256 | 1.599 | 6 | 38.983 |
9 | 603000000 | QAM256 | 2.400 | 9 | 40.946 |
10 | 609000000 | QAM256 | 2.099 | 10 | 38.983 |
11 | 615000000 | QAM256 | 2.299 | 11 | 40.366 |
12 | 621000000 | QAM256 | 2.500 | 12 | 40.366 |
13 | 633000000 | QAM256 | 3.400 | 13 | 40.946 |
14 | 639000000 | QAM256 | 3.299 | 14 | 40.946 |
15 | 645000000 | QAM256 | 3.099 | 15 | 40.366 |
16 | 279000000 | QAM256 | -1.700 | 1 | 38.983 |
17 | 657000000 | QAM256 | 3.500 | 17 | 40.366 |
18 | 663000000 | QAM256 | 3.700 | 18 | 40.366 |
19 | 669000000 | QAM256 | 3.799 | 19 | 40.946 |
20 | 675000000 | QAM256 | 3.599 | 20 | 40.366 |
21 | 681000000 | QAM256 | 3.599 | 21 | 40.366 |
22 | 687000000 | QAM256 | 3.799 | 22 | 40.366 |
23 | 693000000 | QAM256 | 4.199 | 23 | 40.366 |
24 | 699000000 | QAM256 | 4.400 | 24 | 40.366 |
25 | 705000000 | QAM256 | 3.900 | 25 | 40.366 |
26 | 711000000 | QAM256 | 3.799 | 26 | 40.366 |
27 | 717000000 | QAM256 | 3.799 | 27 | 40.366 |
28 | 723000000 | QAM256 | 3.900 | 28 | 40.366 |
29 | 825000000 | QAM256 | 5.500 | 29 | 40.946 |
30 | 831000000 | QAM256 | 5.199 | 30 | 40.366 |
31 | 837000000 | QAM256 | 5.099 | 31 | 40.946 |
32 | 843000000 | QAM256 | 5.099 | 32 | 40.366 |
Receiver | FFT type | Subcarr 0 Frequency(MHz) | PLC locked | NCP locked | MDC1 locked | PLC power(dBmv) |
0 | NA | NA | NO | NO | NO | NA |
1 | 4K | 275600000 | YES | YES | YES | -0.200001 |
Port ID | Frequency (MHz) | Modulation | Signal strength (dBmV) | Channel ID | Bandwidth |
1 | 36996000 | 64QAM | 46.270 | 8 | 6400000 |
2 | 22100000 | 64QAM | 45.260 | 5 | 3200000 |
3 | 30596000 | 64QAM | 46.270 | 7 | 6400000 |
4 | 25300000 | 64QAM | 45.260 | 6 | 3200000 |
5 | 0 | QAM_NONE | - | --- | 1600000 |
6 | 0 | QAM_NONE | - | --- | 1600000 |
7 | 0 | QAM_NONE | - | --- | 1600000 |
8 | 0 | QAM_NONE | - | --- | 1600000 |
Channel Index | State | lin Digital Att | Digital Att | BW (sc's*fft) | Report Power | Report Power1_6 | FFT Size |
0 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
1 | DISABLED | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 0.0000 | 2K |
08-08-2020 05:49 PM - edited 08-08-2020 06:04 PM
Are you running any other Rogers services such as Nextbox's or Home Phone? I'm wondering about that as your DOCSIS 3.0 upstream channels are higher than normal, which is around 30 to 32 dBmV. A splitter installed for multiple services would or could explain that difference in output power levels. Or, this could be a result of the new firmware.
Ok, so, the upper DOCSIS 3.0 channels (1 to 32) look ok. Your signal levels are fine as are the signal to noise ratios. The signal level low point is at 279 Mhz at -1.7 dbmV, next point after that is 579 Mhz at 1.799 dBmV. That covers the entire OFDM range, so there's an upwards signal slope running. Question is, does it break the allowable limits? @RogersAndy would be able to tell you that. Beyond that, above 750 Mhz, the signal levels rise, which is unusual, nice to see as they usually drop, so it looks like Rogers has done some work in your area replacing old equipment. Given that the modem's OFDM channel is running, these DOCSIS 3.0 channels aren't used.
The OFDM channel might be ok, but, there isn't enough data to really know. @RogersAndy will have to let you know.
Your upstream channels are running higher than normal, as indicated above, but, again, part of that might be caused by a splitter, which drops the signal levels in both directions. As a result, the Cable Modem Termination System (CMTS) commands the modem to run higher upstream levels to counteract the upstream signal drop due to the splitter.
The problem with having to unplug and plug the modem back in is that it causes the signal levels to return to their normal levels, even if there is a problem with the external cabling. The one exception would be if the external cables and connectors were severely degraded. Prior to reaching that point, a modem reboot/restart can temporarily resolve cable issues, but it doesn't solve the underlying problems that exist with the cabling or its connectors. Ideally one has to be able to log into the modem at any time to review the signal data, looking for any possible problems. For now, the user interface is not operational after a period of time, but it appears that tech support and the moderators would be able to see that data via the TR-69 path into the modem. Not ideal, but, that works. We're going to have to wait for the next firmware version (I hope) to see this situation corrected.
So, for now, just following a modem restart, the signal levels look ok. Give that a few hours and try to log back into the modem to grab the signal levels again, just to see if their starting to diverge from the data shown above.
Hunting for intermittent connections and latency:
First step, look for lost packets between the modem and CMTS, using a pc or laptop connected via ethernet to the modem or router. This can't be done via wifi due to wifi's usual losses that occur.
1. Run a trace to anywhere, for example to google: tracert -4 www.google.ca
2. With the modem in Gateway mode, or the modem in Bridge mode with a router behind it, the first IP address in the trace is the modem, or router, depending on what the modem operating mode is. The second IP address is the CMTS. Use this address to ping the CMTS.
3. Ping the CMTS using that address and run the test for at least an hour, longer if you prefer:
ping -n 3600 xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the trace's second hop IP address.
That test will run for one hour and then terminate. Ignore the higher return times as they will be due to an internal modem timing issue introduced in version 2.0.10.27. That issue is also present in new firmware version. The question is, what's the lost packet count?
4. You can run that test for several hours by using:
ping -t xxx.xxx.xxx.xxx You will need to use Ctrl c (simultaneous use) to bail out of the test.
To look for packet loss and potential latency, ping the Rogers primary IPV4 DNS address: 64.71.255.204
Ping -n 3600 64.71.255.204 Once again that will run for one hour and terminate automatically. Run that for a long er period by increasing the "3600" figure, or use:
ping -t 64.71.255.204
For the ping test to the CMTS and DNS, you should be at or less than 0.1 % losses.
For the ping test to the DNS, you should in a 9 to 13 milli-second range for an average. If you take a glance at the test occasionally you should not be seeing regular high time ping times. But, once again, we're in that situation that you noted since January where packet loss and high latency have been observed by Rogers and TPIA customers.
To copy the results from the command box, right click on the top title bar of the command box and select Edit ..... Select All. Right click again and select Edit .... Copy. Then you can paste that data into something like notepad so that you can grab the bottom results and paste those results into a post.
Also to note, it appears that Rogers has a throttling policy on the go, for which I haven't seen any official notice. It appears to be Covid related, but no one but Rogers employees probably know the details. There are standing terms and conditions that Rogers has in the event that you're a bandwidth hog, but, this appears to go beyond those stated terms and conditions. If you use remote backups, tying up a lot of upstream bandwidth over the course of a 24 or 48 hour period, you will find your upload rates throttled back to somewhere around 5 Mb/s or so for at least 24 hours, perhaps longer. This is an anecdotal observation by other users, both Rogers and TPIA. This is where @CommunityHelps should step in and clear the air, so that everyone knows what the policy actually is.
Ok, that should do it for now, personal opinion I'd keep the 4582 and return the CGN3. Any odd results that you see for packet loss or latency won't be due to the modem, unless its tied to poor performance of the OFDM channel. In that case the correct solution is to dispatch a tech to resolve the cable / connectors issues or any issues further upstream, and not avoid the issue by switching to the CGN3 which uses the higher frequency SC-QAM channels for its downstream data. Fix the problem instead of avoiding it .......
08-08-2020 08:14 PM
We do have two Rogers PVRs, but they are older Explorer models rather than the newer Nextbox units. As for splitters, you actually helped me look into that when I first started the journey of diagnostics haha, it was initially wired into an unnecessary secondary splitter in the 7dB port, so it was at 10.5dB of loss total, whereas now we only have one splitter in use and the modem is in the 3.5dB port. Since around April, the numbers for our upstream have been around 42-43 dBmV, and 45-46 this summer, and the splitter was swapped for a new one in a tech visit early this year so I’m guessing it is high due to some other factor.
Glad to hear that all looks good on the other signal levels, and that is encouraging that it implies older equipment being replaced in the area! I’ll definitely reach out to Andy and see if he can look into the extra data to check that all is good there.
Yeah I’d become aware of it resetting the signal levels during the process, it is unfortunate as I’d regularly check the levels to see if anything stuck out or changed, but I can say that prior to the firmware update not allowing access to the page, the numbers all have been relatively consistent with the one’s I’ve posted. Additionally it has been a few hours since I re-plugged it and the numbers are basically identical, the downstream signal strength numbers appear to all be around .2 or .3 higher but are similar to what I’ve seen in the past months, lowest being around -1 and the rest averaging 2-5dBmV. When talking to support the other day, the modem purposely hadn’t been re-plugged in a couple weeks, and nothing was noteworthy enough for the representative to bring that up either.
I’ll definitely run those ping tests again to see what they find as I haven’t done them in a while, we’ve just been doing quick ping tests to www.google.com through Mac OS’s network recently. I’ll update with some of those results later.
That is unfortunate in regards to throttling, but I guess I can understand it as the infrastructure wouldn’t account for the unprecedented amount of usage during Covid, thankfully I have just enough physical storage to not need offsite backups currently, but it is something I’ve been looking into.
I agree with your points on the CGN3 and will contact them in regards to that after hopefully confirming the OFDM results with Andy, and either way would prefer to keep the newer unit for what it is worth. During the tech visits pre Covid we had the RG6 ends cut and connectors replaced, along with the new splitters and new section of external RG6, but there is still a small section that wasn’t replaced and the overhead line could be aging, so I’ll try to push for a tech to be dispatched if we continue to experience the issues.
Really appreciate you taking the time to help and give your input, cheers!