cancel
Showing results for 
Search instead for 
Did you mean: 

Brutal latency/ping Recently

t27c
I plan to stick around

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 ***

956 REPLIES 956

Re: Brutal latency/ping Recently

AngryChicken
I plan to stick around

Rogers has acknowledged that in many communities the available bandwidth has become saturated due to ongoing pandemic issues with stay-at-home workers and learners.  Traditionally Rogers approach with dealing with customers' complaints where connectivity issues are concerned has been to "roll a truck" and lay a new cable or to change the customers' modems or all of the above.  This is wasteful both in time and materials in cases where they know it's a capacity issue.  I am still paying >$100/month for Internet service that, when it is consistent, is very fast.  It's also the only show in town and I'm stuck with it until Rogers "segments/splits the node" in my community.  This was supposed to be done 6 months ago, and now I've been told that we will have to wait at least 5 more.  It will be almost a year later than promised by the time it is done, and in the meantime Rogers will have collected >$1000 of my money and for a substandard and inconsistent service. 

 

But..... Rogers customer service (and the employees on this forum) has been very good to deal with and they have been honest with the challenges they are having in my area via private messages.  My issue isn't with the customer service team because they have to play the cards they are dealt in the face of customer complaints.  This they have done with patience and calm and I appreciate it.  The issue is with the network engineering and planning within Rogers.  They have taken the somewhat cynical approach of taking our money and hiding behind the excuse of the disease pandemic for their recalcitrance and procrastination in rolling out new infrastructure.  Disease pandemic aside, this is a missed opportunity since it damages the reputation of the brand and causes a lot of churn with their customers as they cast about and try to find a solution with a different vendor which works.  Some of us have the luxury of choice.  Some of us don't.

 

I am a network engineer, and I am inclined to wait (again I don't have a choice, anyway) for the oft-promised network capacity increase to finally take place in my community.  I am frustrated that another vendor's fibre optic Internet solution terminates only .5 km from my house and is only available in a new subdivision.  In the meantime, I am using that other vendor's DSL Internet solution as a backup and have configured my home WiFi such that it automatically switches to the backup solution when Rogers cable internet is having one of its many "moments" over the course of the day. 

Re: Brutal latency/ping Recently

darwood
I've been here awhile

High Ping rates to upstream gateway. I'm having a problem explaining to Live Chat agent that there is high ping rates with my connection. 

We replaced the modem, but the same issue exists. 

 

The agent seems to think these numbers are normal. 

 

64 bytes from 99.249.108.1: icmp_seq=391 ttl=63 time=108 ms
64 bytes from 99.249.108.1: icmp_seq=392 ttl=63 time=13718 ms
64 bytes from 99.249.108.1: icmp_seq=393 ttl=63 time=13126 ms
64 bytes from 99.249.108.1: icmp_seq=394 ttl=63 time=12106 ms
64 bytes from 99.249.108.1: icmp_seq=395 ttl=63 time=11172 ms
64 bytes from 99.249.108.1: icmp_seq=396 ttl=63 time=10426 ms
64 bytes from 99.249.108.1: icmp_seq=397 ttl=63 time=9400 ms
64 bytes from 99.249.108.1: icmp_seq=398 ttl=63 time=8388 ms
64 bytes from 99.249.108.1: icmp_seq=399 ttl=63 time=7369 ms
64 bytes from 99.249.108.1: icmp_seq=400 ttl=63 time=6480 ms
64 bytes from 99.249.108.1: icmp_seq=401 ttl=63 time=5463 ms
64 bytes from 99.249.108.1: icmp_seq=402 ttl=63 time=4452 ms
64 bytes from 99.249.108.1: icmp_seq=403 ttl=63 time=3535 ms
64 bytes from 99.249.108.1: icmp_seq=404 ttl=63 time=2568 ms
64 bytes from 99.249.108.1: icmp_seq=405 ttl=63 time=1600 ms
64 bytes from 99.249.108.1: icmp_seq=406 ttl=63 time=1352 ms
64 bytes from 99.249.108.1: icmp_seq=407 ttl=63 time=2083 ms
64 bytes from 99.249.108.1: icmp_seq=408 ttl=63 time=3498 ms
64 bytes from 99.249.108.1: icmp_seq=409 ttl=63 time=2757 ms
64 bytes from 99.249.108.1: icmp_seq=410 ttl=63 time=2031 ms
64 bytes from 99.249.108.1: icmp_seq=411 ttl=63 time=1130 ms
64 bytes from 99.249.108.1: icmp_seq=412 ttl=63 time=722 ms
64 bytes from 99.249.108.1: icmp_seq=413 ttl=63 time=3512 ms
64 bytes from 99.249.108.1: icmp_seq=414 ttl=63 time=5189 ms
64 bytes from 99.249.108.1: icmp_seq=415 ttl=63 time=4286 ms
64 bytes from 99.249.108.1: icmp_seq=416 ttl=63 time=5063 ms
64 bytes from 99.249.108.1: icmp_seq=419 ttl=63 time=5342 ms
64 bytes from 99.249.108.1: icmp_seq=422 ttl=63 time=14447 ms
64 bytes from 99.249.108.1: icmp_seq=423 ttl=63 time=13651 ms
64 bytes from 99.249.108.1: icmp_seq=424 ttl=63 time=14552 ms
64 bytes from 99.249.108.1: icmp_seq=425 ttl=63 time=13679 ms
64 bytes from 99.249.108.1: icmp_seq=426 ttl=63 time=12851 ms
64 bytes from 99.249.108.1: icmp_seq=427 ttl=63 time=11863 ms
64 bytes from 99.249.108.1: icmp_seq=428 ttl=63 time=10935 ms
64 bytes from 99.249.108.1: icmp_seq=429 ttl=63 time=9919 ms
64 bytes from 99.249.108.1: icmp_seq=430 ttl=63 time=8900 ms
64 bytes from 99.249.108.1: icmp_seq=431 ttl=63 time=7879 ms
64 bytes from 99.249.108.1: icmp_seq=433 ttl=63 time=5833 ms
64 bytes from 99.249.108.1: icmp_seq=434 ttl=63 time=4811 ms
64 bytes from 99.249.108.1: icmp_seq=432 ttl=63 time=6862 ms
64 bytes from 99.249.108.1: icmp_seq=435 ttl=63 time=3793 ms
64 bytes from 99.249.108.1: icmp_seq=436 ttl=63 time=2769 ms
64 bytes from 99.249.108.1: icmp_seq=437 ttl=63 time=1770 ms
64 bytes from 99.249.108.1: icmp_seq=438 ttl=63 time=750 ms
64 bytes from 99.249.108.1: icmp_seq=439 ttl=63 time=281 ms
64 bytes from 99.249.108.1: icmp_seq=440 ttl=63 time=55.1 ms
64 bytes from 99.249.108.1: icmp_seq=441 ttl=63 time=652 ms
64 bytes from 99.249.108.1: icmp_seq=442 ttl=63 time=959 ms
64 bytes from 99.249.108.1: icmp_seq=443 ttl=63 time=225 ms
64 bytes from 99.249.108.1: icmp_seq=444 ttl=63 time=85.9 ms
64 bytes from 99.249.108.1: icmp_seq=445 ttl=63 time=37.9 ms
64 bytes from 99.249.108.1: icmp_seq=446 ttl=63 time=36.9 ms
64 bytes from 99.249.108.1: icmp_seq=447 ttl=63 time=611 ms
64 bytes from 99.249.108.1: icmp_seq=448 ttl=63 time=281 ms
64 bytes from 99.249.108.1: icmp_seq=449 ttl=63 time=1545 ms
64 bytes from 99.249.108.1: icmp_seq=450 ttl=63 time=683 ms
64 bytes from 99.249.108.1: icmp_seq=451 ttl=63 time=55.2 ms
64 bytes from 99.249.108.1: icmp_seq=452 ttl=63 time=49.7 ms
64 bytes from 99.249.108.1: icmp_seq=453 ttl=63 time=102 ms
64 bytes from 99.249.108.1: icmp_seq=454 ttl=63 time=9406 ms
64 bytes from 99.249.108.1: icmp_seq=455 ttl=63 time=8683 ms
64 bytes from 99.249.108.1: icmp_seq=456 ttl=63 time=7721 ms
64 bytes from 99.249.108.1: icmp_seq=457 ttl=63 time=6702 ms
64 bytes from 99.249.108.1: icmp_seq=458 ttl=63 time=5680 ms
64 bytes from 99.249.108.1: icmp_seq=459 ttl=63 time=4721 ms
64 bytes from 99.249.108.1: icmp_seq=460 ttl=63 time=3700 ms
64 bytes from 99.249.108.1: icmp_seq=461 ttl=63 time=2681 ms
64 bytes from 99.249.108.1: icmp_seq=462 ttl=63 time=1660 ms
64 bytes from 99.249.108.1: icmp_seq=463 ttl=63 time=689 ms

 

 

.....

 

^C
--- 99.249.108.1 ping statistics ---
1456 packets transmitted, 1354 received, 7.00549% packet loss, time 1466356ms
rtt min/avg/max/mdev = 7.617/1648.750/19428.989/2887.074 ms, pipe 19

Re: Brutal latency/ping Recently

-G-
Resident Expert
Resident Expert

@darwood wrote:

High Ping rates to upstream gateway. I'm having a problem explaining to Live Chat agent that there is high ping rates with my connection. 

We replaced the modem, but the same issue exists. 

 

The agent seems to think these numbers are normal. 


The fact that your upstream router (and default gateway) is slow in responding to ping requests is noteworthy, but you also need to keep in mind that responding to those ping requests is at the absolute bottom of the router's priority list.

 

When running ping tests to troubleshoot a latency/packet loss problem, I actually run three ping-tests side-by-side simultaneously that are in lock-step with one another: One to a fast server on the Internet (e.g. Google DNS / 8.8.8.8) , another to my local modem/router, and another to the CMTS router, my router's default gateway.  If I get a slow ping response from 8.8.8.8, it's because something, somewhere in the network is introducing latency.  If I also get a fast response from my local router, it confirms the problem is NOT on my local LAN or WiFi and probably not due to a problem with my modem/router.  If I get a similarly slow ping RTT from the CMTS router, it pretty much confirms that the congestion is in my local node.  If I get an even slower ping response from the CMTS router, it confirms congestion in my local node AND confirms that the CMTS router's main processor is VERY busy doing something... and if its routing tables are in flux and the local node/CMTS router is blocked from forwarding packets as a result, then that is what is causing your latency...  and if the latency is severe enough and the traffic loads are high enough, you will also get packet loss.

Re: Brutal latency/ping Recently

@Datalink Rogers told me don’t continuously ping the node it can get my service suspended is that true ?

Re: Brutal latency/ping Recently


@lethalsniper wrote:
@Datalink Rogers told me don’t continuously ping the node it can get my service suspended is that true ?

We (RE's) would not know... this is really a question for the @CommunityHelps  team... but it would not surprise me if Rogers did suspend the account of a customer doing that.  It's kinda pointless to constantly ping the node/CMTS router, unless it is a relatively brief, focused test to correlate with other data... and if the node is overloaded, you would only be putting the node under more duress by hammering the processor with ping requests.

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast
Who do I ask ? And thanks. I mean @Datalink has many post about it on here so wouldn’t @communityhepls have deleted those post ?

Re: Brutal latency/ping Recently


@lethalsniper wrote:
Who do I ask ? And thanks. I mean @Datalink has many post about it on here so wouldn’t @communityhepls have deleted those post ?

I just posted about this.  Some may ping the CMTS router because that ping target produces the highest round trip times and the numbers can look bad... but that round trip time is inflated and not a good measure of the actual latency, and you would also be exacerbating problems on an already overloaded node.  It's one thing to perform a relatively brief, focused ping test.  However, if you continuously hammer their node with pings 24/7 or do anything else that disrupts service in your area, then they are within their rights to suspend you.

Re: Brutal latency/ping Recently

AngryChicken
I plan to stick around

^^^ How does a continuous ping constitute a burden on their network, let alone "hammering" it?  Not being argumentative, rather pointing out that sending out small ICMP echo packets is pretty thin ground to suspend someone's service.  Contracts have at least 2 signatories.  This is not an abuse of their service but rather a test on the customer's part to confirm that they are getting the service that they paid for.

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast
Then what is the accurate way to find out if it’s a congested issue on the node ? Our speeds drop during the day and night .. and if I’m not mistaken @Datalink always recommend people on here to ping the node which is on hop2 for at least 3600 so what I’m trying to get here if we are pinging the node after our modem why would @CommunityHelps allow people to share that information on here if we can get our Rogers account suspended?

Re: Brutal latency/ping Recently


@AngryChicken wrote:

^^^ How does a continuous ping constitute a burden on their network, let alone "hammering" it?  Not being argumentative, rather pointing out that sending out small ICMP echo packets is pretty thin ground to suspend someone's service.  Contracts have at least 2 signatories.  This is not an abuse of their service but rather a test on the customer's part to confirm that they are getting the service that they paid for.


If you want to measure latency on your service, use something like 8.8.8.8 as a ping target.

 

Your CMTS router's processor does things like compute routes and maintain a routing table that specialized hardware uses for making forwarding decisions, and adding to its load can actually contribute to additional latency.

 

I am not saying that Rogers would suspend your service.... I honestly don't know... just saying why they might.  I will leave it up the @CommunityHelps  team to provide an official response.

Re: Brutal latency/ping Recently

AngryChicken
I plan to stick around

I work for the vendor of that router which is likely 1st hop into Rogers core from the CMTS.  I doubt very much that a continuous ping, even by hundreds of customers simultaneously, would be any more of a big deal to that router than a flea on a hippo.

Re: Brutal latency/ping Recently

@lethalsniper  I don't think that sending 3600 pings to the CMTS router, one second apart for one hour, would be a problem.  Doing it continuously, day after day, month after month, without end is another thing, especially when it does not even provide an accurate measurement of your latency.

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast
When pinging 8.8.8.8 how long should I let it run for ?

Re: Brutal latency/ping Recently


@lethalsniper wrote:
When pinging 8.8.8.8 how long should I let it run for ?

If you are just doing a test, not continuous monitoring, I would do simultaneous ping tests to 8.8.8.8 , the CMTS router, and to my local router, for the reasons that I mentioned in my previous post.  If you are just measuring latency, 600 pings (10 minutes) should be enough.  To also get a better measurement of packet loss, 3600 ping (1 hour) is better.

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast
And that won’t put a load on the node if I ping 8.8.8.8 for 1 hour ?

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast

 

@-G- 

 

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=116
Reply from 8.8.8.8: bytes=32 time=19ms TTL=116
Reply from 8.8.8.8: bytes=32 time=248ms TTL=116
Reply from 8.8.8.8: bytes=32 time=11ms TTL=116


Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 248ms, Average = 73ms

 

 

1 2 ms 1 ms 2 ms puma7-atom.ht.home [192.168.0.1]
2 14 ms 14 ms 16 ms 99.240.xxx.x
3 19 ms 12 ms 10 ms 8078-dgw02.ym.rmgt.net.rogers.com [66.185.89.101]
4 16 ms * 15 ms 0-4-0-9-cgw01.bloor.rmgt.net.rogers.com [209.148.233.213]
5 20 ms 14 ms 11 ms 209.148.235.30
6 24 ms 21 ms 16 ms 72.14.209.126
7 14 ms 14 ms 13 ms 209.85.249.15
8 17 ms 12 ms 14 ms 216.239.42.61
9 84 ms 19 ms 12 ms yyz12s05-in-f14.1e100.net [172.217.164.238]

 

 

nging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=12ms TTL=116
Reply from 8.8.8.8: bytes=32 time=9ms TTL=116
Request timed out.
Reply from 8.8.8.8: bytes=32 time=14ms TTL=116

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
Approximate round trip times in milli-seconds:
Minimum = 9ms, Maximum = 14ms, Average = 11ms

 

Re: Brutal latency/ping Recently


@lethalsniper wrote:
And that won’t put a load on the node if I ping 8.8.8.8 for 1 hour ?

No.  If you are just sending traffic to and from another server on the Internet, that's fine because it does not put any load on the node's processor modules.

 

 

FYI, I just sent 100 pings to 8.8.8.8 and to my local CMTS router and got the following results:

 

Ping statistics for 8.8.8.8:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 17ms, Average = 10ms

 

Ping statistics for [deleted]:
Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 17ms, Average = 9ms

 

That's normal for me now.  Note that the ping round trip times to dns.google and the CMTS router are also almost identical.. so the CMTS router is responding to my pings immediately, indicating that its CPU is not under any significant load.

 

Going back 9 months ago, when things were REALLY bad in my area, the ping RTTs to dns.google were spiking to > 10000ms and the RTTs for corresponding pings to the CMTS router were spiking to > 12000ms.  My local router was responding instantaneously.  I also ran pings and traceroutes from my XB6 gateway and confirmed that my local node basically stopped forwarding traffic for up to 10 seconds at a time, which is practically an eternity in network time.  On top of that, the CMTS router was taking 2000ms to respond to pings, confirming that its processor was under very heavy load, and whatever it was doing likely put the node into a state where it could not forward packets for several thousand milliseconds at a time... which also caused traffic to build up in the input queues and caused some traffic to get lost if any queues overflowed.

 

If you are seeing periodic ping spikes but the ping RTTs to dns.google and the CMTS are almost the same, the node is probably just getting loaded due to traffic volumes.  Rogers should be able to confirm that.

 

If the CMTS router is taking hundreds or thousands of milliseconds longer to respond than dns.google, then your node's processer is extraordinarily busy doing something that that might cause your node to cease forwarding network packets.  Your average Rogers support tech may not be able to confirm this.

 

If traffic is getting backed up in the node for whatever reason, the signal and line stats to your modem could still look perfectly normal... which may result in a support tech saying that there is no problem on the Rogers network.

Re: Brutal latency/ping Recently


@lethalsniper wrote:

Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=14ms TTL=116
Reply from 8.8.8.8: bytes=32 time=19ms TTL=116
Reply from 8.8.8.8: bytes=32 time=248ms TTL=116
Reply from 8.8.8.8: bytes=32 time=11ms TTL=116


Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 11ms, Maximum = 248ms, Average = 73ms


Rogers does not provide any service guarantees of any kind but even they say that you should not see ping RTTs (to a well-connected host) that exceed 100ms.  This is where a simultaneous ping test to the CMTS router comes in handy; if it takes as long (or longer) for the CMTS router to respond, then the latency is almost certainly being introduced by the local node.

Re: Brutal latency/ping Recently

lethalsniper
I'm an enthusiast
Ping statistics for 172.217.1.164: www.google.com
Packets: Sent = 1452, Received = 1443, Lost = 9 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 516ms, Average = 13ms

And as for the CMTS when pinging I’m getting roughly 528 ms

Re: Brutal latency/ping Recently

AngryChicken
I plan to stick around
I just received a pleasant surprise. An agent from the office of the president of Rogers called me. We had a pleasant chat while I laid out very calmly the challenges my community has been having with Rogers’ Internet service. I was left with the feeling that he agreed with my points and he said he would do what he could to escalate and move up the planned late summer network upgrade to address these congestion issues. Colour me impressed.

Re: Brutal latency/ping Recently

borisnet
I plan to stick around

Thank you for the reply @AngryChicken  - while there is no way to confirm your statement, it seems to point at network congestion.

It is still a bit bizarre that the congestion happens so punctually and not for a longer period of time.