@riotvale This has been an ongoing issue for many people over the last month or two, and has been reported and discussed at length in the following thread: https://communityforums.rogers.com/t5/Internet/Brutal-latency-ping-Recently/td-p/454780
I'm not a gamer but do have Ignite TV. After many months of trouble-free service, I started to see audio and video dropouts. For some reason, the CMTS/CMTS router stops forwarding network packets, sometimes for several seconds. This is REALLY bad for any latency-sensitive network applications.
I reported the issue and it has mostly been resolved, at least for me. (I still see quite a bit of jitter but it's fairly minor. Pings typically have a RTT of < 15 ms although it can sometimes spike to 100 ms.) However, several users are still reporting severe latency spikes and packet loss.
Nearly 6 hours of ping plotter and this is the result. Rogers said I shouldn't worry about the PL to the ipv4 primary DNS previously.....
Looks like the first major issue area is their internal 10.202...... server....
(Left out my local first hop then went back and put the field names, hence the splice)
@onyxapple your post has been moved to this thread as the thread is appropriate for your current situation. If you read thru many of the posts in this thread, you will see that you're not the only affected by the latency problem. This is an ongoing problem since January and affects Rogers and TPIA customers as well. Rogers is radio silent on the situation so no one has any real solutions to the problem. While tech support can check the modem signal levels to determine if their within spec, they really don't check for packet loss unless pressed to do so. In the current situation, the problem is at or beyond the Cable Modem Termination System (CMTS) which your modem connects to. That is beyond tech support and requires the network engineering staff to resolve. Sorry I don't have better news for you 😞
@Tolo What modem do you have? If its a CGN3xxxx or white CODA-4582, you will see false packet loss from pingplotter for the modem and CMTS (hop #2) when you ping a target beyond Hop #2. If you ping the modem only you shouldn't see any packet loss. If you ping the CMTS (hop #2), you will see false packet loss from the modem while the CMTS hop should not exhibit any packet loss. When you ping a target beyond hop #2, you will see packet loss from both the modem and CMTS, where you just proved to yourself that both are free of any packet loss.
As for the ping test to the Rogers Primary DNS 64.71.255.204, you shouldn't see anything but the occasional rare packet loss from the DNS.
Looking at your ping test, that looks pretty ugly. Run a command line ping test to the DNS just to see what results you get. The command line ping should confirm the results that you see with Pingplotter.
@Tolo have a look at the following post and consider running a TCP/IP ping test to the same DNS address:
https://communityforums.rogers.com/t5/Internet/Brutal-latency-ping-Recently/m-p/458014#M59641
Pingplotter will run a single address test to the selected address. That would be interesting to see both latency and packet loss for the same route using TCP/IP instead of ICMP.
@nomad1984 wrote:
@-G- How did you manage to report the issue where Rogers actually looked into it past the "we don't see anything from our end" tech support calls? I have tried 6 times now, to no avail, I posted in here earlier with extensive notes and logs but not sure how to actually have that information consumed by Rogers and connected to my account / area, etc.
When they say "we don't see anything from our end" they would be right. Signals to the modem look just fine.
Posting logs is great but they only show spikes in path latency. It's not easy for Tech Support or the network teams to find what's actually causing it.
When I run a ping test on a Linux system, I normally see 8 - 12 ms ping times to 8.8.8.8. When things got really bad, I constantly started seeing something like this:
64 bytes from 8.8.8.8: icmp_seq=3451 ttl=55 time=8004 ms
64 bytes from 8.8.8.8: icmp_seq=3452 ttl=55 time=7002 ms
64 bytes from 8.8.8.8: icmp_seq=3453 ttl=55 time=5978 ms
64 bytes from 8.8.8.8: icmp_seq=3454 ttl=55 time=4954 ms
64 bytes from 8.8.8.8: icmp_seq=3455 ttl=55 time=3930 ms
64 bytes from 8.8.8.8: icmp_seq=3456 ttl=55 time=2906 ms
64 bytes from 8.8.8.8: icmp_seq=3457 ttl=55 time=1882 ms
64 bytes from 8.8.8.8: icmp_seq=3458 ttl=55 time=858 ms
When this happens, Ignite TV freezes, FaceTime freezes, etc. There's no packet flow in either direction for 8+ seconds. Ping times before and after this blip are < 15 ms.
In that last example, if I were to run a traceroute on my XB6 gateway to 8.8.8.8 the moment that my pings freeze, the first hop (the CMTS router) has an RTT of 8000+ ms ; the remaining hops get processed after the CMTS freeze subsides and they have a RTT of < 15 ms.
If I run a simultaneous ping test to 8.8.8.8 and to my CMTS in two separate windows, during the "freeze", I would actually also see higher RTTs to the CMTS router. So, not only does it stop forwarding packets for a few seconds, it's REALLY busy doing something that has a higher priority than responding to my ICMP Echo Request.
This is not the sort of thing that you can report by calling in to Tech Support. In this case, I worked with the @CommunityHelps team. After some back-and-forth with the Mods, they created a ticket on my behalf and forwarded all of my test results for further investigation. A few days later, things went back to normal.
@GotRobbed I should hope not. This only got fixed for me a few days ago. They likely backed out a change on my node and probably on just a few others as well. Now that they know that the problem has been fixed for me, they would then have to devise a plan for what they need to do network-wide, short-term and long-term. (I have my guesses as to what they were doing and why this happened. Rogers won't confirm my suspicions so I won't post anything here.)
You know, if thats what it took, to point out a high activity period for the CMTS, there's no reason that Rogers shouldn't be able to review the all of the CMTS records looking for spikes in activity, either CPU or traffic, and correlate that to the ongoing processes in the CMTS. I would think that the CPU activity and traffic levels should be recorded at least every minute, if not more. This should be a matter of searching thru the data looking for markers that indicate the same set of circumstances.
@nomad1984 wrote:
@-G- Thank you for the quick and thorough reply, I posted earlier about my symptoms and attempts to fix them: https://communityforums.rogers.com/t5/Internet/Brutal-latency-ping-Recently/m-p/458131#M59682
Do the results I posted coincide with what you were experiencing as well? I know that my modem is the model that provides false packet loss on hop#2. Is there any other test I can run other then what I posted in that post that I could send to Rogers that may assist them in troubleshooting?
Many thanks again!
Yeah, that's pretty consistent with what I saw. The only difference now is that this problem now has a known cause.
I actually came to the same conclusions using different tools and techniques and used those to validate the results. My challenge was then coming up with a way to show what was going on with simple tools and accurate timestamps. I also ran some critical tests (e.g. the traceroute) using Rogers own equipment.
If Rogers continues to give you grief for using your own equipment, you may have to take your Rogers modem out of bridge mode and use its internal tools as part of your testing.
@Datalink wrote:
You know, if thats what it took, to point out a high activity period for the CMTS, there's no reason that Rogers shouldn't be able to review the all of the CMTS records looking for spikes in activity, either CPU or traffic, and correlate that to the ongoing processes in the CMTS. I would think that the CPU activity and traffic levels should be recorded at least every minute, if not more. This should be a matter of searching thru the data looking for markers that indicate the same set of circumstances.
What complicates things is that Rogers may (??) now be using Casa Systems' Axyom vBNG Router (and vCCAP?) and expanding what they are doing with it. With various network functions virtualized, they would have a whole new set of issues to troubleshoot and a bunch of things that may not show up with conventional logging.
Rogers doesn't want to spend money or have resource to do this. plain and simple.
As I said along with others on this forum, check other service providers in your area and if you can get similar speed run...
I'm ready to even go to Bell 100 since I'm just done...
Can even watch ignite TV for more than 20 min without freezing or audio drop
-
207318 views
-
156 Likes
-
-
