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.
- last edited on by
RogersHarry
Hi
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
Thanks
@st_brown the latency that you see with hop #2 is due to a firmware change that occurred with April 2017 with version 2.0.10.27. 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.
@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 8.8.8.8 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.
--- 8.8.8.8 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.
@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.
@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).
- last edited on 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 🙂
- last edited on 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?
- last edited on 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.
Closeup view:
https://communityforums.rogers.com/t5/media/gallerypage/image-id/9560i50778ABF199BDC76
Sequential tests: download (small spike), upload (larger spike), again and again .....
https://communityforums.rogers.com/t5/media/gallerypage/image-id/9559i36FF1C8F05347F37
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.
@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.
-
211161 views
-
156 Likes
-
-
