01-30-2020 12:15 AM - last edited on 01-30-2020 08:22 AM by RogersTony
I am wired, with the gigabit package and all of the sudden have gotten constant ping spikes for over the last few days. I haven't been able to play any games online because the crazy ping spikes and latency make it completely unplayable. My speeds are what they are expected to be, no issues there. I have tried hard wiring straight into the modem but alas, the issue still persists. I have tried switching cables, power cycling my devices, factory resetting my devices. The issue still persists. I have called and contacted Rogers multiple times and they say everything seems fine on their end. But still, the issue persists and is steady. resulting in me not able to use any of my gaming devices due to the brutal and constant ping spikes. It's frustrating paying over $100 a month for internet I cant use for the things I want it for. Any help or suggestions are welcomed and appreciated. Thank you
*** Edited Labels ***
05-28-2020 09:33 PM
I've noticed that too. I remember one night I had awful jitter and stuttering, then I started downloading COD: MW in the background, I then ran a ping plotter test and had perfect internet even while downloading a 100gb game. I'm sure rogers prioritizes your internet while downloading/gaming.
05-29-2020 10:17 AM - edited 05-29-2020 10:17 AM
I see similar results here.
While pings look similar (spikes), gaming experience is far less painful than before. I would agree with you guys and say that Rogers is prioritizing gaming traffic. I have received less complaints regarding audio quality while on my SIP calls. Fairly certain they moved SIP traffic up there too to be prioritized.
On another note, my "tentative date" for node segmentation is scheduled for Dec 7. Maybe we'll have decent internet in 2021 guys🤣
05-29-2020 12:56 PM
As far as I can tell, it looks like the Network team actually fixed the underlying issues that had been introducing (sometimes extreme) latency at the edge, which caused traffic to back up in busier nodes (which, in turn, caused packet loss for many) and which crippled latency-sensitive applications for us all.
I don't know if we will ever get an official explanation of what exactly happened or what they did to fix it. I'm just happy that it has been fixed for me and am hopeful that is has also been fixed (or will be fixed soon) for everybody.
06-02-2020 04:51 PM
Unfortunately for me it looks like the issues are still just as present as ever 😞 I'm glad they've recovered for you and hope that is a sign that more people will have improvements soon as well. Anyone else notice any changes recently?
Last night our network actually went down and didn't come back on its own for the first time in a long while, it lasted around 15 minutes until I unplugged the modem and router to reset them both. When looking at the modem before rebooting, the lights that were on were all green instead of the usual two blue ones with the rest green. As of today, the ping has been reaching 500ms+ and I'm experiencing around 8% packet loss on one device, and other devices are experiencing the same ping spikes but without the high packet loss. For the past two or three months we've had regular spikes to 200ms on all devices and around 0.5-1% packet loss, which makes working remotely very difficult but still doable, today's results have made it much more difficult again.
I keep going back and forth on believing we might have issues that are still unsolved on our end and thinking it likely is just the infrastructure issues at play, as there are so many variables (RG6 outside replaced at our house improved issues we'd been having with 7000ms+ pings, but they only replaced one half of the cable, as previous work has a splice with one of those metal connectors before the RG6 enters the house, different OS on computers that experience packet loss vs those that don't, no glaring issues with our DOCSIS chart, it goes on..) so for now I just keep waiting, but I'm hoping that based on your experience something might've been discovered and it is just a process of rolling out the fixes. Curious if anyone else has any changes to their situation as well, cheers all.
06-03-2020 12:47 PM
Playing Warzone......0% packet loss to.....BOOM 12% aarrrgghhh.
06-06-2020 05:12 PM
Just noticed today that my modem firmware has changed to 6T8 from 6T6. Is this recent, or is that how they implemented traffic priority for gaming?
06-09-2020 10:18 AM - last edited on 06-09-2020 10:52 AM by RogersHarry
I usually have a problem where every 4-7 or so days I get some packet loss and I end up needed to reboot my modem and that typically resolves the issue (CODA-4582). I notice it from when im playing online games and I just drop out of the game. I can also ping -t an address and see some request time outs.
I decided to contact Rogers support on the weekend and they sent a ticket to the network team and they didn't see any issues. Modem signals were good.Next step is they want to send a tech out to my condo building.
I tried using Ping Plotter and at the time the packet loss went away but I do see high latency on hop 2 and a bit on 3. Is that normal on rogers network or is it a Ping plotter issue? I sometimes see the latency when doing tracert's on the second hop as well but its intermittent
06-10-2020 01:42 AM - edited 06-10-2020 01:46 AM
@st_brown the latency that you see with hop #2 is due to a firmware change that occurred with April 2017 with version 188.8.131.52. The changes were made to improve multi-protocol performance of the modem, but, the drawback is the increase in latency from the Cable Modem Termination System (CMTS) when you ping the CMTS using an ICMP ping. That CMTS latency has been carried forward thru all 4582 firmware versions ever since.
If you were to decrease the interval time manually by typing in 0.020 or 0.015 which is 15 or 20 milliseconds, you will see a couple of issues, packet loss from the modem and CMTS and latency from the CMTS. The packet loss from the modem and CMTS seen in low interval testing is due to a modem timing issue. That packet loss will be seen if you ping a target beyond the CMTS. If you:
1. Ping the modem, you shouldn't see any packet loss from the modem. The response time should be less than 1 millisecond, so you should be able to reduce the interval down to something like 0.005 (seconds) and reduce the chart timing down to 60 seconds. There's more to this but its rather late at night.
2. Ping Hop #2 next, you shouldn't see any packet loss from Hop #2, but, you will see false packet loss from the modem, where you just proved to yourself that there was no packet loss from the modem. Use something like 0.02 (seconds) or larger for ping intervals.
3. Ping a target beyond Hop #2, you will see packet loss from both the modem and Hop #2, where you've already proven that there is no packet loss from either one. Use something in the order of 0.250 or larger for short tests, moving to 1 second pings for 24 hour tests or longer.
With a low ping interval when you ping Hop #2 (CMTS), you'll see a far higher number of high ping times from the CMTS on the plot. Keep in mind, this if from the CMTS only and has no effect on targets beyond the CMTS.
Now, if you were to ping the CMTS at 1 ping/second for the entire day, I'd expect you to see low ping times very early in the morning, in the 2 am to 6 am time period, and potentially higher ping times in the evening hours when people are home, streaming, gaming, etc. Significantly higher ping times from the CMTS in the evening would signify a high load data throughput load on the neighbourhood node or CMTS.
06-10-2020 09:05 AM
06-10-2020 04:20 PM
So I have started observing the same issues starting a few weeks back in the middle of May (this is in Markham-Thornhill, ON - Highway 7/Bayview area)
I have called tech support 3 times, and as with everyone else, they have indicated they were unable to detect any problems.
Below is some stats that others are also providing - hoping that this can be resolved soon as it is impacting my productivity whilst working from home, as well as my ability to enjoy any type of gaming during the evenings.
My tests are done with my PC that is connected via ethernet cable directly to the modem (Hitron CODA-4582) - the wifi is currently disabled as I have a third-party access point installed. I have also done tests with all other devices connected, and simply using my laptop or PC connected to the modem directly.
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Signal noise ratio (dB)|
|Receiver||FFT type||Subcarr 0 Frequency(MHz)||PLC locked||NCP locked||MDC1 locked||PLC power(dBmv)|
|Port ID||Frequency (MHz)||Modulation||Signal strength (dBmV)||Channel ID||Bandwidth|
|1||30596000||ATDMA - 64QAM||32.250||3||6400000|
|2||36996000||ATDMA - 64QAM||32.250||4||6400000|
|3||13696000||ATDMA - 64QAM||32.000||1||6400000|
|4||23700000||ATDMA - 64QAM||32.250||2||6400000|
|Channel Index||State||lin Digital Att||Digital Att||BW (sc's*fft)||Report Power||Report Power1_6||FFT Size|
Pinging Rogers DNS
Ping statistics for 184.108.40.206:
Packets: Sent = 2643, Received = 1883, Lost = 760 (28% loss),
Approximate round trip times in milli-seconds:
Minimum = 3ms, Maximum = 2453ms, Average = 174ms
06-10-2020 05:18 PM - edited 06-10-2020 07:30 PM
@benz370 Your downstream power levels are a bit high and upstream power levels are a bit low but all still within acceptable limits. SNR on the downstream QAM channels is normal, and not shown on the downstream OFDM channel so Rogers will have to check that for you. It's not apparent to me what is causing your latency issues and packet loss, and your modem does not display correctable and uncorrectable codeword error stats.
If you check the logs, is your modem logging any errors?
I would send a private message to @CommunityHelps to see if one the Mods can check the load on your local node and error stats on both your node and your modem. I would also retry your ping tests on another Internet host, such as 220.127.116.11 to see if they replicate.
I just ran a ping test as well and my latency stats still continue to be quite good. With the higher temperatures, I am seeing more uncorrectable codeword errors than normal but nothing alarming.
--- 18.104.22.168 ping statistics ---
2000 packets transmitted, 2000 received, 0% packet loss, time 2001880ms
rtt min/avg/max/mdev = 5.514/10.871/46.812/2.477 ms
I think that your problems may be due to a local issue rather than what had caused the higher-than-normal latency and spikes that so many of us had been seeing for several months... but that is just speculation on my part. A higher-level tech really needs to investigate your issue further.
06-10-2020 07:27 PM - last edited on 06-10-2020 07:39 PM by RogersMaude
Hi @-G- ,
Thank you for your response! Will definitely reach out to @CommunityHelps later today.
Below is the errors currently reported on the modem
|1||01/01/1970 00:01:00||82000200||critical||No Ranging Response received - T3 time-out;CM-VER=3.1;|
|2||06/09/2020 00:06:57||90000000||warning||MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-VER=3.1;|
|3||06/10/2020 00:06:54||68010300||error||DHCP RENEW WARNING - Field invalid in response v4 option;CM-QOS=1.1;CM-VER=3.1;|
|4||06/10/2020 05:58:38||84020200||warning||Lost MDD Timeout;CM-QOS=1.1;CM-VER=3.1;|
Results pinging Google DNS:
Ping statistics for 22.214.171.124:
Packets: Sent = 600, Received = 600, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 1295ms, Average = 105ms
06-10-2020 08:14 PM
@benz370 Well, you are not getting a ton of errors in your log, so that's good. I can't say when that T3 Timeout occurred but the other errors are benign. However, your ping RTTs to Google's DNS are not really any better than your previous test.
There's definitely something that Rogers needs to look into. I don't know if @Datalink has anything else to add.
06-10-2020 08:56 PM
@benz370 as indicated, your downtream signal levels are higher than normal, but, that shouldnt' cause huge issues. You're just at the borderline where users start to see issues. The DOCSIS downstream limits are +/- 15 dBmV, but, typically users start to see issues long before those limits are every reached.
Your upstream levels are fine for this modem. They appear low when compared to any other modem, but the 4582 is more than happy to run in that 30 to 32 dBmV range.
Ok, if you're seeing short disconnects, they won't show up in the signal levels. The log might show effects, but, there's no guarantee of that either. The MDD timeouts might be an indication of the disconnects. Tech support should be able to see the record of modem connections with the CMTS, so that should be a good heads up that there is a potential cable or connector issue afoot.
What I would recommend is to ping the Cable Modem Termination System (CMTS) which is Hop #2 on any trace.
1. tracert -4 www.google.ca
2. ping Hop #2, which is the CMTS: ping -n 3600 xxx.xxx.xxx.xxx where this address is Hop #2
What you're looking for is packet loss between the modem and the CMTS. Ignore any high ping times that you see as thats a modem timing issue that causes high times from the CMTS. Any targets beyond the CMTS are not affected by the timing issue.
Fwiw, here's the signal path to the Cable Modem Termination System, which controls the modems that are connected to it as well as providing data services to those modems:
1. Modem to cable ingress splitter or amp (a splitter or amp will be present if you have more than one Rogers service running)
2. Splitter to external demarcation point (something like this which shows fibre instead of cable: https://www.gomultilink.com/categories/demarcation-enclosures/custom-enclosure)
3. Demarcation point to local tap (pedestal or utility pole)
4. Local tap to neighbourhood node
5. Neighbourhood node to CMTS
From modem to local tap, this is RG-6 cable.
From local tap to neighbourhood node, this is hard cable
From neighbourhood node to CMTS is fibre optic.
Normally if there is an issue, that issue is with the external cable run from the external demarcation point to the local tap. This is usually resolved by replacing the external cable and/or its connectors. The external cable and its connectors don't last forever and have to be replaced every few years. That might be a couple of year, it might be 15 years or more, don't know what the real average happens to be. So, replacing that cable and its connectors is fairly routine. There is always the possibility of problems further upstream, starting at the local tap (pedestal or utility pole) or further beyond. If for example the external cable was replaced completely and the issues persisted, that points to issues further upstream.
Normally the cabling in the home remains stable and trouble free, but, there is always the possibility of an in home cable issue.
Hope this helps. Next step, personal opinion is to go hunting for any packet loss between the modem and CMTS (read local tap).
06-12-2020 01:25 AM - last edited on 06-12-2020 08:19 AM by RogersCorey
So I'm located in Waterloo, Ontario. Had 150Mpbs internet in my apartment, Directly connected with me and my friend desktop with LAN cable with the modem. Both PC had the same issue.
fast.com test result shows: 300Mbps~, Latency Unloaded 11ms, Loaded 400ms~(no less than 350ms every test recently) Upload Speed: 14Mpbs
I had this spike high Ping and high package lost during gaming(Overwatch US server). For example, the ping and package will both spikes up about 20 seconds every 5 to 10 minutes sometimes even dense. The game's match is completely unplayable because the package lost and high ping!
It happens a few months since I moved into my new apartment. I contacted customer service last October and switch the modem on Rogers store nearby but the issues still constantly happen. I also tried portforward but still can't fix the issue.
I chated with customer service again a few days ago and the agent just said the internet and modem are totally healthy and said it's possibly caused by smart home appliances like smart light etc. However, it totally doesn't make scenes because I don't have anything like that. I even test the internet with WiFi switch off and only connect with my PC only, the issue still existed.
Wating for experts reply ASAP and I will try reply with any info you guys need ounces I got emails.
Thank you very much!
06-12-2020 02:20 AM - last edited on 06-12-2020 08:19 AM by RogersCorey
@ChenDuoCJ what exactly do you mean when you say "Latency Unloaded" and "Loaded"?
Does unloaded imply that you're just running the speedtest without anything else running, and does loaded imply that you're running an upload or download of some type at the same time that you're running the speedtest. The result of the simultaneous upload/download with a speedtest would most certainly result in a higher latency number.
Just trying to understand the exact meaning of your post 🙂
06-12-2020 02:29 AM - last edited on 06-12-2020 08:19 AM by RogersCorey
Hi Datalink, thanks for replying and sorry about the confusion, I should including the screenshot in the first places.
Here's what I mean, So what else you need to troubleshooting my situation?
06-12-2020 02:50 AM - last edited on 06-12-2020 08:20 AM by RogersCorey
No apologies necessary 🙂 I'm just looking to ensure my interpretation of your post. The image has to be approved by a moderator before its publicly available, so, I won't be able to see it until later in the morning when one of the moderators is on duty. Won't know if I need any other info until then. Have a good evening.
Not sure what we're discussing at this point, but, just as a demonstration with Pingplotter, here's what happens when you run a ping test and then start a speedtest. This is the closeup view. The latency spikes are the download portion of the test followed by the upload portion of the test. So, that shows what happens to the ping latency as the speedtest is running, which should be very similar to any other situation where you run a latency dependent application and run a download or upload at the same time.
Sequential tests: download (small spike), upload (larger spike), again and again .....
Basically the modem has to decide what should be processed first, resulting in ICMP latency spikes. Anyone looking to change the priority of the data types would have to run a router that allows QOS categories that can be changed, in terms of their processing priority.
06-12-2020 06:08 PM
06-16-2020 01:38 AM - edited 06-16-2020 01:41 AM
@ChenDuoCJ I haven't forgotten about you, just a little slow in responding. One question at this point, when you ran the speedtests, did you set the latency test to run during the upload portion of the test to show the loaded test results? You can do that by going into the settings for the test, which has a link just below the test results. If so, then the test results do make sense and they would look similar to the results that I posted with my simultaneous ping and speedtest plots.
I will respond with a longer post, just can't get to it tonight.
06-16-2020 08:23 AM