Hello, @hndz-daniel.
Thank you for posting your concern, and welcome to our Community!
Experiencing intermittent slow speeds in the evenings can be frustrating. I appreciate you connecting with our tech support. Sometimes isolating the root cause of the intermittent speed drops becomes challenging.
We can further investigate this for you; please send us a private message at @CommunityHelps. You can find details about our private messaging in this blog.
Cheers,
RogersMoin
Two weeks of communicating through private messages and I have not seen anything new done from support. Every time I contact said support, I talk with a new person who immediately believes restarting the modem is the solution and then when that doesn't work, they raise a ticket with supposed technicians who then send me a text several days later saying that nothing was resolved because they couldn't find the issue. Then I contact support again and it's a new person, and it is back to ground zero.
This has been going on for months.
These are the speeds I am dealing with virtually every evening:
Internet, phone and TV are all effectively unusable. For some reason this has been getting worse since the last support ticket was raised.
What am I paying this company for?
@hndz-daniel Which Ignite Internet service do you currently subscribe to? The subject line says, "Extremely slow internet & TV in the evenings since moving to fiber" but you also said, "The best results came when [the technician} installed a coax attentuator behind our modem, and that reduces the impact of the slowness in the evenings but not by much."
Sounds like you have DOCSIS (Cable) Internet, not FTTH.
Also, when you say, "Basically, the problems started ever since Rogers upgraded my neighborhood to fiber/ignite earlier this year.", what kind of upgrades are you referring to?
@hndz-daniel : Are you testing with WiFi? If so, please do a test with a computer connected with Ethernet directly to the Gateway/modem. It's possible that all your neighbours at home may affect your WiFi too, instead of congestion on the node. Check out the following thread on slow speeds and WiFi FAQs:
https://communityforums.rogers.com/t5/Internet/Slow-Speeds/m-p/510588#M75402
@hndz-daniel Is 1 Gigabit really the fastest speed that is available in your area, not 1.5 Gigabit?
Rogers is currently in the process of upgrading old fibre nodes to newer technology, which will allow them to offer higher speeds to Cable Internet customers, but it hasn't been a smooth process. A number of customers in Markham have been reporting a wide range of issues. For some, it has been instability. For others, their biggest issue has been latency and jitter. For some, their nodes are overloaded. A number of people also report slower speeds after upgrading to the 1.5 Gigabit service, which could be caused by any of a number of things outside of Rogers' control.
I'm not sure what to make of your speed test results. It's almost unbelievable that your connection could be THAT slow. The curve on your graph is also VERY jaggedy, and your ping time and jitter is very high. Do you see the same speed tests results with another computer, even one that is connected by Wi-Fi? For the most accurate test results, your computer should not have any background tasks running, not syncing folders with a cloud service, and you should have ALL of your browser tabs closed and run nothing but the speed test.
Here is what the graph should look like:
I'm also in Markham, and my fibre node also got upgraded back in March. No, it has not been an entirely smooth process, but my speeds are fine and I have not noticed any major stability issues lately.
What are your speed test results like when you test at off-peak hours?
Also, have you tried any other test sites, such as https://www.waveform.com/tools/bufferbloat ?
Have you also performed the tips for Troubleshooting a Slow or Intermittent Connection?
When performance gets that bad for you, surely Rogers would be able to determine whether it is a problem in your home, affecting you and your immediate neighbours, or whether it is a more widespread issue.
If you find that your Internet performance suddenly drops, I would suggest sending a private message to @CommunityHelps so that they can investigate. If you know that your speeds drop at predictable times in the day, I would send them a PM in advance so that they can authenticate you, access your account, and be in a position to troubleshoot immediately when you contact them next.
Thank you for the insight. I am going to continue monitoring tonight.
Sorry, I should have explained my tests better. The test results I posted are from a workstation in a different room connected to the modem via powerline adapter with cat6 cables inbetween. Yes, it is jittery, however the results are generally consistent until the evenings when you get those results.
I have another workstation hooked up directly to the modem via cat6 cable, right underneath the modem itself. The cable is only a few feet long. We'll call this Workstation A. These are the results for workstation A during off-hours:
These are our expected speeds, which I am fine with. It shows that my house is entirely capable of receiving the plan that we are paying for.
However, this test was taken from last night:
I did use the same web tools for testing here, however I neglected to screenshot the Rogers one last night. They had the same results. No, I did not have any background applications running.
When performance gets that bad for you, surely Rogers would be able to determine whether it is a problem in your home, affecting you and your immediate neighbours, or whether it is a more widespread issue.
I would hope so, but every ticket they have raised so far ends in zero results. Every time, I am contacted by a different person telling me they didn't find anything. I have done this dance several times over the past several months.
Next time this happens (most likely tonight), I am going to test using those other tools you've posted and then post those results.
@hndz-daniel Our residential power in Markham is not the cleanest. Your performance with those power line network adapters can vary greatly. Really, you should only be testing with a DIRECT Ethernet connection to the Ignite Gateway.
As for your Ethernet cables, with 2.5 GigE, the spec says you can use Cat 5e for runs up to 100m. That is what I am (mostly) using. That you are using Cat 6 is great but it is not essential. However, things get much more finnicky at higher speeds and when you are operating at the maximum allowable distances.
Alright, the issue is hitting us right now. I've disconnected all third party devices and below are the test results on Computer A, which I've done at about 10pm. I want to reinforce that this is coming from a computer only a few feet away from the gateway, connected directly via Cat6 cable.
I also went into my modem and pulled these charts, as per the troubleshooting guide you sent me:
| Downstream | Channel Bonding Value | |||||||||||||||||||||||||||||||||
| Channel ID | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 |
| Lock Status | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked | Locked |
| Frequency | 597 MHz | 627 MHz | 849 MHz | 855 MHz | 861 MHz | 579 MHz | 585 MHz | 591 MHz | 603 MHz | 609 MHz | 615 MHz | 621 MHz | 633 MHz | 639 MHz | 645 MHz | 651 MHz | 657 MHz | 663 MHz | 669 MHz | 675 MHz | 681 MHz | 687 MHz | 693 MHz | 699 MHz | 705 MHz | 711 MHz | 717 MHz | 723 MHz | 825 MHz | 831 MHz | 837 MHz | 843 MHz | 350000000 | 920000000 |
| SNR | 45.2 dB | 45.3 dB | 44.1 dB | 44.3 dB | 43.9 dB | 45.4 dB | 45.3 dB | 45.3 dB | 45.0 dB | 45.3 dB | 45.2 dB | 45.3 dB | 45.2 dB | 45.2 dB | 45.2 dB | 45.0 dB | 45.0 dB | 45.0 dB | 45.2 dB | 43.8 dB | 45.0 dB | 45.0 dB | 45.0 dB | 44.9 dB | 45.0 dB | 44.9 dB | 44.9 dB | 44.7 dB | 44.5 dB | 44.5 dB | 44.4 dB | 44.3 dB | 45.0 dB | 43.4 dB |
| Power Level | 2.6 dBmV | 2.4 dBmV | 2.4 dBmV | 2.3 dBmV | 2.1 dBmV | 2.5 dBmV | 2.5 dBmV | 2.5 dBmV | 2.5 dBmV | 2.5 dBmV | 2.5 dBmV | 2.5 dBmV | 2.4 dBmV | 2.4 dBmV | 2.4 dBmV | 2.4 dBmV | 2.4 dBmV | 2.4 dBmV | 2.4 dBmV | 2.3 dBmV | 2.2 dBmV | 2.2 dBmV | 2.2 dBmV | 2.3 dBmV | 2.4 dBmV | 2.4 dBmV | 2.5 dBmV | 2.5 dBmV | 2.6 dBmV | 2.5 dBmV | 2.5 dBmV | 2.4 dBmV | 1.6 dBmV | 2.3 dBmV |
| Modulation | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | 256 QAM | OFDM | OFDM |
| Upstream | Channel Bonding Value | ||||
| Channel ID | 1 | 2 | 3 | 4 | 10 |
| Lock Status | Locked | Locked | Locked | Locked | Locked |
| Frequency | 21 MHz | 25 MHz | 32 MHz | 38 MHz | 42 MHz |
| Symbol Rate | 2560 | 5120 | 5120 | 5120 | 0 |
| Power Level | 42.0 dBmV | 45.5 dBmV | 45.5 dBmV | 46.5 dBmV | 41.2 dBmV |
| Modulation | QAM | QAM | QAM | QAM | OFDMA |
| Channel Type | TDMA_AND_ATDMA | ATDMA | ATDMA | ATDMA | TDMA |
| CM Error Codewords | ||||||||||||||||||||||||||||||||||
| Channel ID | 8 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 |
| Unerrored Codewords | 2174234810 | 3964524593 | 3964530855 | 3964535713 | 3964541970 | 3964548833 | 3964558919 | 3964565039 | 3964569256 | 3964575705 | 3964579323 | 3964585655 | 3964590914 | 3964598135 | 3964603042 | 3964608031 | 3964612247 | 3964618982 | 3964620433 | 3964630137 | 3964634650 | 3964644077 | 3964648899 | 3964650738 | 3964658406 | 3964665402 | 3964672357 | 3964676126 | 3964680667 | 3964682309 | 3964682834 | 3964687642 | 2476205098 | 2174234810 |
| Correctable Codewords | 41867 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 245759303 | 41867 |
| Uncorrectable Codewords | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
I'm not sure what other info I could provide, but if there is anything else that I can do that can help us find the root of this problem, please let me know.
I should note that even though it is showing that we are having about 100-200mbps of download, all of our devices are struggling to even access the internet. The TVs are choppy when we try to watch something. I would be more than happy if we actually had 200mbps of download since that would even be enough to suit our needs, but it doesn't feel like we are actually getting that much.
@hndz-daniel There's nothing wrong with the connection to your modem. Your stats are fine... so either your node got into a REALLY bad state where it could barely forward packets or there is an upstream problem, or both.
Did you happen to perform a ping test? I'm wondering whether your connection is just really slow, whether you are getting sporadic packet loss, or whether network traffic is getting dumped for 10's of seconds at a time.
Looking at your channel config, I see that in addition to the OFDM channel at 350 MHz, you also have a second OFDM channel at 920 MHz, which I currently do not have... but when they tried to get this configuration working in my area back in March, I had all sorts of stability issues and the Internet service became totally unusable.
@hndz-daniel, while I agree with @-G- assessment that there shouldn't be anything wrong with the cable signal levels reaching your modem, I will point out that the OFDM and OFDMA signal levels as shown in the Management Information Base are completely hidden from the user. Those MIB signal levels show a breakdown of the OFDM and OFDMA channels into smaller frequency ranges, where each range has its own signal level, a Receive Margin measurement and an overall indication of the behaviour of 98% of the data sub-carriers. All of that information, combined, is used to determine the overall performance of the OFDM downstream and OFDMA upstream channels, and, its completely hidden from the users and the first line tech support staff. As far as I know, the only staff that has access to that information at the tech level are the forum moderators and the Level II techs. So, in terms of assessing the modem performance, until someone tells me otherwise, the majority of the tech staff don't have access to the information that is really required to understand what might be occurring. In the absence of that information, the assessment of the OFDM and OFDMA channels is a best guess based on the signal levels of all of the downstream and upstream channels, the PLC power level of the OFDM channel and the codeword stats for those channels. Unfortunately, there can be a significant range in the signal levels within the space of 100 to 200 Mhz and in the case of the OFDM and OFDMA channels, that is completely hidden from the end user and the first line tech support staff.
The second OFDM channel is rather interesting to see. That suggests that your neighbourhood has been upgraded with higher frequency local taps. If you have underground cabling with Rogers pedestals located throughout the neighbourhood to provide cable service to the houses in the neighbourhood, those pedestals contain a cable tap, which connects the hard cable run from the neighbourhood node to the houses near those pedestals. The cable tap will be similar to the tap seen here on the right hand side:
https://broadbandlibrary.com/taps-a-peek-under-the-hood/
So, in theory, in order to support the higher OFDM downstream channel, those local taps would have to support frequencies up to and possibly beyond 1 GHz. That wouldn't work in my neighbourhood as the local taps only support frequencies up to 860 Mhz.
I agree with @-G- questioning the possibility of packet loss or loss of network traffic for periods of time. The only way to determine that would be a ping test, looking for packet loss. To that end, I suggest running a ping test, but, run that test using Windows Powershell in order to record the results with a timestamp and to record those results to a data file, for further analysis if appropriate.
So, the steps to do that are as follows:
1. At the windows Start button select Search and enter Powershell
2. Select Windows Powershell from the list of programs that are shown
3. With Powershell running, run an IPv4 trace to anywhere, google for example
tracert -4 www.google.com
4. If the modem is running in Gateway mode, the IP address at Hop #2 is the Cable Modem termination System (CMTS). If the modem is running in Bridge mode with a router behind it, the modem is invisible to the trace and Hop #2 is the CMTS address. Ping the CMTS.
5. In order to produce a time stamp with the results, run the following command in Powershell, where xxx.xxx.xxx.x is the IP address of the CMTS:
Ping.exe -t xxx.xxx.xxx.x | ForEach {"{0} - {1}" -f (Get-Date),$_}
or, to run a 24 hour ping test which terminates upon completion, use:
Ping.exe -n 86400 xxx.xxx.xxx.x | ForEach {"{0} - {1}" -f (Get-Date),$_}
where xxx.xxx.xxx.x is the CMTS address from Hop #2.
6. In order to record the data to a file, you need to decide where to place the data file. To record the data, you use the following Powershell command to write the data to the file:
Start-Transcript -path C:/temp/PingLog.txt -Append
In my case I have a temp directory on the C drive, and in this case I titled the data file as Pinglog.txt
You can change the directory where the file is held and the file name to a location and name of your choice.
So, before you start the ping test, you use the Start-Transcript command.
Then run the ping test for the amount of time that you want. I'd recommend a full 24 hour ping test. Whenever I do this I usually run it from midnight to midnight. So the next command is:
Ping.exe -n 86400 xxx.xxx.xxx.x | ForEach {"{0} - {1}" -f (Get-Date),$_}
When the test terminates, stop the transcript:
Stop-Transcript
So the whole list of command would look like the following, using powershell instead of the Windows command prompt:
tracert -4 www.google.com
Start-Transcript -path C:/temp/PingLog.txt -Append
Ping.exe -n 86400 xxx.xxx.xxx.x | ForEach {"{0} - {1}" -f (Get-Date),$_}
Stop-Transcript
Note, you can run a trace with the command to produce a timestamp as well:
tracert www.google.com | ForEach {"{0} - {1}" -f (Get-Date),$_}
At the end of this test, you will see the packet loss throughout the day and from the data file, determine if the packet loss appears to be completely random or if there is any pattern to the loss.
The next step beyond this is to run a TCP/IP ping test to the CMTS or possibly Rogers DNS if the CMTS refuses to respond to a TCP/IP ping.
To do that, download Microsoft's PsPing from:
https://learn.microsoft.com/en-us/sysinternals/downloads/psping
From what I remember, you have to download the whole PsTools files. Ok, when that is done, copy PsPing64.exe to a directory of your choice. This is a command line application, like tracert or ping. The same procedure as indicated above is used to determine the CMTS IP address, and the same commands to start and stop the transcript are used. The difference here is that you're using a TCP/IP ping instead of an ICMP ping. You will see that a typical response time is in the order of 1 ms using TCP/IP instead of 10 or more ms using an ICMP ping.
For the Powershell TCP/IP ping the .\psping64 command is required for powershell, specificaly the .\ at the front of the command
for the CMTS ping test, the test uses port 53 as the TCP/IP target port:
to run a test which will continue until you terminate the test with a Ctrl c use:
.\psping64 -t -i 1 xxx.xxxxxxx.x:53 | ForEach {"{0} - {1}" -f (Get-Date),$_}
to run a fixed length test, 24 hours for example where there is one ping every second, use;
.\psping64 -n 86400 -i 1 xxx.xxx.xxx.x:53 | ForEach {"{0} - {1}" -f (Get-Date),$_}
If your CMTS won't respond to a TCP/IP ping, use Rogers DNS address for TCP/IP ping test:
to run a test which will continue until you terminate the test with a Ctrl c use:
.\psping64 -t -i 1 64.71.255.204:53 | ForEach {"{0} - {1}" -f (Get-Date),$_}
to run a fixed length test, 24 hours for example where there is one ping every second, use;
.\psping64 -n 86400 -i 1 64.71.255.204:53 | ForEach {"{0} - {1}" -f (Get-Date),$_}
Note that to run a test to a DNS address, use port 53. To run a test to web site, use port 80
You can run a test to any other DNS using port 53. Its just a matter of changing the IP address in the command. The same goes for running a test to a web site, google for example. You will find that the web sites response to a TCP/IP ping is much higher that a DNS response. I suspect that it mirrors the results that you would see with an ICMP test.:
.\psping64 -t -i 1 www.google.com:80 | ForEach {"{0} - {1}" -f (Get-Date),$_}
Ok, that should do it. The interesting question is whether or not you end up with packet loss in a TCP/IP test. I can see that with an ICMP test as ICMP response is apparently at or near the bottom of the processing list for any server that you ping. I don't remember if I've ever run into a situation where a server refused to answer although the point is brought up by numerous people. The CMTS might refuse to answer the ping. It just depends on how its configured. If it refuses to answer, then ping the DNS. I don't expect to see any TCP/IP packet loss from either the CMTS or DNS, but if it happens it should be a rare occurrence. If you ended up with regular packet loss in a TCP/IP test, then something is afoot, and, with by using Powershell, you will have the results to back up your statements.
@KA0S_11 raises a good point. Has the modem ever been replaced?
@hndz-daniel FYI, I sent a PM earlier today to one of my network support contacts. Hopefully they can look into this further.
@Datalink This is a DAA / R-PHY node. Before deploying these, there's an advance team that ensures the plant in the area is capable of 1.2 GHz spectrum support, or whatever they plan to provision at the time of the cut-over. There are also no errors on the 920 MHz downstream OFDM channel in the stats, so that's not the problem. However, it looks like the hardware/software in the new R-PHY node is still not entirely stable in some configurations.
-
10144 views
-
6 Likes
-
-
