What is going on with ping and latency on Rogers network?

[roytoy]

I switched from Teksavvy VDSL 25/10 to Rogers 1.5gbps fiber several months ago. I was very surprised to find a significant increase in latency across almost every game server I play on. This is also taking into account my previous VDSL line had a first hop of 6ms to reach teksavvy. My Roger's fiber is <1ms to reach Rogers and yet my pings are easily 10-20ms worst than my old Teksavvy VDSL connection in end to end ping times.

I am not talking about packet loss or wifi issues here. I am wired and always <1ms to reach Rogers without any packet loss to Rogers. There appears to be a big latency gap between Rogers and the following networks.

Furthermore, and even more curiously, these ping/lantecy issues only appear to occur on IPv4. IPv6 seems unaffected. I can ping the same networks significantly faster on IPv6. The pings I get on IPv6 are the ping times that should be expected on IPv4. Due to these issues, Bell, Teksavvy and pretty much any other provider has better performance than Rogers for gaming, Voip and all realtime streaming applications on IPv4.

Here are some MTR for google's DNS.

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 689 | 689 | 0 | 0 | 2 | 0 |
| 173.33.156.1 - 0 | 689 | 689 | 0 | 0 | 2 | 0 |
| 209.148.230.57 - 0 | 689 | 689 | 0 | 1 | 4 | 1 |
| 209.148.233.121 - 0 | 689 | 689 | 1 | 1 | 3 | 2 |
| 209.148.235.222 - 0 | 689 | 689 | 2 | 3 | 39 | 3 |
| Request timed out. - 100 | 138 | 0 | 0 | 0 | 0 | 0 |
| 74.125.244.161 - 0 | 689 | 689 | 14 | 14 | 17 | 14 |
| 216.239.41.175 - 1 | 685 | 684 | 15 | 15 | 35 | 15 |
| 8.8.8.8 - 0 | 688 | 688 | 14 | 14 | 16 | 14 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 683 | 683 | 0 | 0 | 1 | 0 |
| 173.33.156.1 - 0 | 683 | 683 | 0 | 0 | 3 | 1 |
| 209.148.230.57 - 0 | 683 | 683 | 0 | 1 | 12 | 1 |
| 209.148.230.121 - 0 | 683 | 683 | 1 | 1 | 3 | 2 |
| 209.148.235.222 - 1 | 671 | 668 | 2 | 3 | 54 | 2 |
| Request timed out. - 100 | 137 | 0 | 0 | 0 | 0 | 0 |
| 108.170.250.241 - 0 | 683 | 683 | 15 | 15 | 19 | 15 |
| 216.239.35.233 - 0 | 683 | 683 | 28 | 28 | 43 | 28 |
| 8.8.4.4 - 0 | 683 | 683 | 27 | 27 | 28 | 27 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 2607:fea8:fd10:[redacted] - 0 | 677 | 677 | 0 | 0 | 1 | 0 |
| 2001:506:20:7fc0:0:2091:4825:5065 - 0 | 676 | 676 | 0 | 0 | 2 | 0 |
| 2607:f798:10:187b:0:2091:4823:57 - 0 | 676 | 676 | 0 | 1 | 5 | 1 |
| 2607:f798:10:cae:0:2091:4823:3121 - 0 | 676 | 676 | 1 | 1 | 5 | 2 |
| 2607:f798:10:35c:0:2091:4823:5222 - 0 | 676 | 676 | 2 | 3 | 55 | 3 |
| 2607:f798:14:83::2 - 0 | 676 | 676 | 2 | 3 | 180 | 2 |
| 2001:4860:0:17::1 - 1 | 672 | 671 | 2 | 2 | 4 | 3 |
| 2001:4860:0:1::1591 - 12 | 459 | 404 | 3 | 3 | 13 | 3 |
| 2001:4860:4860::8888 - 0 | 676 | 676 | 2 | 2 | 4 | 2 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 2607:fea8:fd10:[redacted] - 0 | 616 | 616 | 0 | 0 | 5 | 0 |
| 2001:506:20:7fc0:0:2091:4825:5065 - 0 | 616 | 616 | 0 | 0 | 2 | 0 |
| 2607:f798:10:187b:0:2091:4823:57 - 0 | 616 | 616 | 1 | 1 | 11 | 1 |
| 2607:f798:10:188d:0:2091:4823:7037 - 0 | 616 | 616 | 1 | 1 | 7 | 2 |
| 2607:f798:10:35c:0:2091:4823:5222 - 0 | 616 | 616 | 1 | 4 | 72 | 2 |
| 2607:f798:14:83::2 - 0 | 616 | 616 | 2 | 2 | 181 | 2 |
| 2001:4860::1c:4001:57f0 - 30 | 281 | 197 | 3 | 3 | 5 | 4 |
| 2001:4860:0:1::5b65 - 0 | 616 | 616 | 2 | 2 | 5 | 3 |
| 2001:4860:4860::8844 - 0 | 616 | 616 | 2 | 2 | 4 | 2 |

Same number of hops, but a huge difference in ping times.

Here are MTRs to Quad9.

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 619 | 619 | 0 | 0 | 1 | 0 |
| 173.33.156.1 - 0 | 619 | 619 | 0 | 0 | 2 | 0 |
| 209.148.230.57 - 0 | 619 | 619 | 0 | 1 | 5 | 1 |
| 209.148.230.121 - 0 | 619 | 619 | 1 | 1 | 5 | 2 |
| 209.148.235.222 - 1 | 611 | 609 | 2 | 3 | 31 | 3 |
| 4.59.180.41 - 0 | 619 | 619 | 27 | 30 | 65 | 28 |
| 4.69.208.178 - 85 | 142 | 22 | 0 | 26 | 27 | 27 |
| 4.68.71.230 - 0 | 619 | 619 | 26 | 27 | 33 | 29 |
| 9.9.9.9 - 0 | 619 | 619 | 39 | 39 | 41 | 39 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 587 | 587 | 0 | 0 | 1 | 0 |
| 173.33.156.1 - 0 | 587 | 587 | 0 | 0 | 4 | 2 |
| 209.148.230.57 - 0 | 587 | 587 | 0 | 1 | 13 | 1 |
| 209.148.233.121 - 0 | 587 | 587 | 1 | 1 | 10 | 1 |
| 209.148.235.222 - 0 | 587 | 587 | 2 | 3 | 43 | 3 |
| 4.59.180.41 - 0 | 587 | 587 | 27 | 29 | 71 | 28 |
| 4.69.208.178 - 96 | 123 | 6 | 26 | 26 | 27 | 26 |
| 4.68.71.230 - 0 | 587 | 587 | 26 | 27 | 37 | 27 |
| 149.112.112.112 - 0 | 587 | 587 | 26 | 26 | 28 | 27 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 2607:fea8:fd10:[redacted] - 0 | 604 | 604 | 0 | 0 | 1 | 0 |
| 2001:506:20:7fc0:0:2091:4825:5065 - 0 | 604 | 604 | 0 | 0 | 2 | 1 |
| 2607:f798:10:187b:0:2091:4823:57 - 0 | 604 | 604 | 1 | 1 | 15 | 1 |
| 2607:f798:10:cae:0:2091:4823:3121 - 0 | 604 | 604 | 1 | 1 | 5 | 1 |
| 2607:f798:10:35c:0:2091:4823:5222 - 0 | 604 | 604 | 1 | 2 | 55 | 2 |
| Request timed out. - 100 | 121 | 0 | 0 | 0 | 0 | 0 |
| 2001:504:1a::34:115 - 58 | 184 | 78 | 2 | 5 | 27 | 3 |
| 2620:fe::fe - 1 | 596 | 594 | 1 | 1 | 111 | 2 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 2607:fea8:fd10:[redacted] - 0 | 580 | 580 | 0 | 0 | 0 | 0 |
| 2001:506:20:7fc0:0:2091:4825:5065 - 0 | 579 | 579 | 0 | 0 | 2 | 0 |
| 2607:f798:10:187b:0:2091:4823:57 - 0 | 579 | 579 | 1 | 1 | 20 | 1 |
| 2607:f798:10:3b6:0:2091:4823:7077 - 0 | 579 | 579 | 1 | 1 | 6 | 1 |
| 2607:f798:10:35c:0:2091:4823:5222 - 0 | 579 | 579 | 1 | 4 | 64 | 22 |
| Request timed out. - 100 | 116 | 0 | 0 | 0 | 0 | 0 |
| 2001:504:1a::34:115 - 49 | 199 | 103 | 2 | 5 | 26 | 3 |
| 2620:fe::9 - 1 | 564 | 560 | 1 | 1 | 6 | 2 |

In this case, the routes are different. But you can still see a sigicant gap after leaving Rogers network on IPv4.

Here is a MTR to I3d.net's Rotterdam server.

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 1697 | 1697 | 0 | 0 | 1 | 0 |
| 173.33.156.1 - 0 | 1696 | 1696 | 0 | 0 | 2 | 0 |
| 209.148.230.57 - 0 | 1696 | 1696 | 0 | 1 | 5 | 1 |
| 209.148.237.77 - 0 | 1696 | 1696 | 1 | 1 | 4 | 1 |
| 209.148.235.222 - 0 | 1696 | 1696 | 1 | 3 | 121 | 4 |
| 213.179.220.6 - 0 | 1696 | 1696 | 13 | 15 | 70 | 14 |
| 109.200.219.1 - 0 | 1696 | 1696 | 13 | 13 | 42 | 13 |
| 109.200.219.4 - 0 | 1696 | 1696 | 20 | 22 | 78 | 23 |
| 109.200.218.79 - 0 | 1696 | 1696 | 33 | 36 | 106 | 34 |
| 109.200.218.86 - 0 | 1696 | 1696 | 94 | 95 | 136 | 94 |
| 109.200.218.84 - 0 | 1696 | 1696 | 94 | 98 | 170 | 95 |
| 109.200.218.245 - 0 | 1696 | 1696 | 107 | 114 | 195 | 115 |
| 213.163.76.133 - 0 | 1696 | 1696 | 94 | 94 | 96 | 95 |

| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 2607:fea8:fd10:[redacted] - 0 | 1696 | 1696 | 0 | 0 | 2 | 0 |
| 2001:506:20:7fc0:0:2091:4825:5065 - 0 | 1696 | 1696 | 0 | 0 | 2 | 1 |
| 2607:f798:10:187b:0:2091:4823:57 - 0 | 1696 | 1696 | 1 | 1 | 13 | 2 |
| 2607:f798:10:44:0:690:6324:8201 - 0 | 1696 | 1696 | 1 | 1 | 8 | 2 |
| 2607:f798:10:35c:0:2091:4823:5222 - 0 | 1696 | 1696 | 2 | 4 | 67 | 7 |
| 2a00:1d25:1::9 - 0 | 1695 | 1695 | 2 | 3 | 47 | 2 |
| 2a00:1630:1fff::4058:2 - 0 | 1695 | 1695 | 2 | 2 | 32 | 2 |
| 2a00:1630:1fff::4060:1 - 0 | 1695 | 1695 | 8 | 10 | 79 | 8 |
| 2a00:1630:1fff::1424:2 - 0 | 1695 | 1695 | 8 | 11 | 94 | 8 |
| 2a00:1630:1fff::1420:1 - 0 | 1695 | 1695 | 87 | 88 | 126 | 103 |
| 2a00:1630:1fff::1518:1 - 0 | 1695 | 1695 | 88 | 92 | 208 | 88 |
| 2a00:1630:1fff::1504:2 - 0 | 1695 | 1695 | 88 | 95 | 200 | 131 |
| 2a00:1630:3401:148:: - 0 | 1695 | 1695 | 88 | 88 | 118 | 88 |

That is just a sample of the higher pings I seen on Roger network. I have other IPv4 addresses I can ping that are always higher than would I can get from a Bell or Teksavvy connection.

[RogersCorey]

Good morning @roytoy!

The observation that IPv6 ping times are much better than IPv4 is an interesting one. That is a good data point. Thank you!

Are you having any other issues with your connection beyond latency while gaming? 

Please keep in mind that our tolerance for ping times before we can escalate a case is 100ms. While as a gamer I understand that is a high ping time, we still need to see ping times in excess of of 100ms before I'll be able to perform a successful escalation. 

I do see that your worst packets are hitting above 100ms but the average is still coming out under that. If you've got some other servers that produce average ping times in excess of 100ms, please provide those tests to us. It would be incredibly helpful to building a case.

Regards,

RogersCorey

[roytoy]

If you must have 100ms trace routes to escalate, then I can provide that.

To further expand on my observations, not only is the ping times unusually high on IPv4 when exiting Rogers network, I also witness fluctuations in the ping times on IPv4. These fluctuation are not peak time depended. They seem to happen at random. For example here is another MTR I did to the same Rotterdam IPv4 address above.

| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 4575 | 4575 | 0 | 0 | 23 | 0 |
| 173.33.156.1 - 0 | 4574 | 4574 | 0 | 0 | 9 | 1 |
| 209.148.230.57 - 0 | 4574 | 4574 | 0 | 1 | 22 | 1 |
| 209.148.237.77 - 0 | 4574 | 4574 | 1 | 1 | 10 | 2 |
| 209.148.235.222 - 1 | 4539 | 4530 | 1 | 3 | 68 | 2 |
| 213.179.220.6 - 0 | 4574 | 4574 | 26 | 28 | 90 | 27 |
| 109.200.219.1 - 0 | 4574 | 4574 | 13 | 13 | 46 | 13 |
| 109.200.219.4 - 0 | 4574 | 4574 | 34 | 36 | 102 | 34 |
| 109.200.218.79 - 0 | 4574 | 4574 | 34 | 37 | 113 | 36 |
| 109.200.218.86 - 1 | 4499 | 4480 | 107 | 109 | 155 | 108 |
| 109.200.218.84 - 1 | 4519 | 4505 | 107 | 121 | 197 | 110 |
| 109.200.218.245 - 1 | 4558 | 4554 | 107 | 113 | 259 | 110 |
| 213.163.76.133 - 1 | 4570 | 4569 | 107 | 108 | 113 | 108 |

In this case it is 107ms to reach the Rotterdam server. Even during this MTR, it is still a constant 88ms to reach on IPv6.

Here is MTR to I3d.net's Frankfurt server

| WinMTR statistics |
| Host - % | Sent | Recv | Best | Avrg | Wrst | Last |
| 192.168.0.1 - 0 | 1305 | 1305 | 0 | 0 | 2 | 0 |
| 173.33.156.1 - 0 | 1305 | 1305 | 0 | 0 | 2 | 0 |
| 209.148.230.57 - 0 | 1305 | 1305 | 0 | 1 | 20 | 1 |
| 69.63.248.201 - 0 | 1305 | 1305 | 1 | 1 | 5 | 2 |
| 209.148.235.222 - 1 | 1301 | 1300 | 2 | 3 | 47 | 3 |
| 213.179.220.6 - 0 | 1304 | 1304 | 13 | 14 | 59 | 13 |
| 109.200.219.1 - 0 | 1304 | 1304 | 13 | 14 | 50 | 14 |
| 109.200.219.4 - 0 | 1304 | 1304 | 20 | 23 | 96 | 21 |
| 109.200.218.79 - 0 | 1304 | 1304 | 34 | 35 | 76 | 35 |
| 109.200.218.86 - 0 | 1304 | 1304 | 94 | 96 | 134 | 98 |
| 109.200.218.84 - 0 | 1304 | 1304 | 94 | 97 | 170 | 95 |
| 109.200.218.63 - 0 | 1304 | 1304 | 123 | 124 | 172 | 123 |
| 188.122.68.53 - 0 | 1304 | 1304 | 104 | 104 | 105 | 104 |

Neither of these servers should be in excess of 100ms to reach.

[_0101_]

I don't have all the data like you do there, if you let me know how to provide it I can. Outside the city of Ottawa on ignite500, the past 2 or 3 weeks I've seen a big spike of latency both in online games and discord chat, so much that other discord users said they can't understand me and I had to disconnect.

When I reported it to support chat, after the 2nd instance in one week, they sent someone out to test it and also the chat agent said there are issues in my area.  The tech came and removed a filter from the back of my modem.  They also recommended the cable from the pole to my house should be changed as it's been there since 2007 when I moved here and before then. They have not come back to change it.

I haven't had any more serious latency issues since then, but I know they can come back at any moment.

My price plan is up in January so I may not stay for long anyhow.

[roytoy]

If you want to help, you can download WinMTR and run some mtr traces to a couple of IPs. Just put in an IP address and let it run for at least 15 minutes and click copy to text and post the results. I like to use DNS IP addresses and I3d.net's ip addresses since they have low latency servers all over the world. You can use the IP addresses I used above (take the last IP in each result).

I am beginning to think the issue is Roger's end point at 209.148.235.222. I just ran an MTR to I3d.net's montreal server, which is 213.179.192.53, for a few hours and there is 14% packet loss on 209.148.235.222 at Rogers side. My connect always exits from 209.148.235.222 and seems to have a latency penalty on IPv4 and packet loss.

Host Snt Rcv Drop Loss% Last Avg Best Wrst StDev Jttr Javg Jmax
1. 173.33.156.1 12999 12988 11 0.1% 0.8 0.5 0.4 6.5 0.5 0.3 0.3 5.9
2. 209.148.230.57 12999 12999 0 0.0% 1.6 0.9 0.9 22.7 1.1 0.2 0.9 21.5
3. 209.148.233.121 12999 12999 0 0.0% 2.1 1.5 1.2 11.4 0.6 0.1 0.4 9.7
4. 209.148.235.222 12999 11128 1871 14.4% 2.7 2.1 1.9 81.1 4.8 0.5 4.0 79.0
5. hosted-by.i3d.net 12998 12998 0 0.0% 15.2 13.4 13.2 82.2 6.1 1.8 5.1 68.8
6. cator1-rt002i.i3d.net 12998 12998 0 0.0% 13.5 13.3 13.2 54.7 3.0 0.2 2.5 41.3
7. casla1-rt001i.i3d.net 12998 12998 0 0.0% 20.6 20.5 20.2 98.3 8.0 0.3 7.2 77.7
8. camtr1-rt001i.i3d.net 12998 12998 0 0.0% 34.1 34.0 33.9 150.7 7.1 0.3 6.0 116.
9. hosted-by.i3d.net 12998 12985 13 0.1% 35.8 33.9 33.8 50.7 2.3 1.3 1.0 11.4

If others on Rogers could MTRs to multiple IPs and post results it would help find confirm where these issues are happening. I would like to see some who is also on the same 209.148.235.222 exit point as me to confirm if it is only me affected or others as well.

[RogersMoin]

Hello, @roytoy & @_0101_.

@roytoy: I appreciate you running the additional tests as suggested by Corey. However, we may be unable to use the test results from third-party apps like WinMTR while submitting a case for investigation. Please use the built-in utilities of your Operating System to run the ping and traceroute commands, as explained in our support article. 

You can send us a private message at @CommunityHelps with the results. We detailed more info about our private messaging in this blog. 

Cheers,

RogersMoin

[roytoy]

From Roger fiber to i3d.net's Montreal server:

Tracing route to hosted-by.i3d.net [213.179.192.53]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     1 ms    <1 ms    <1 ms  173.33.156.1
  3     1 ms     1 ms     1 ms  209.148.230.57
  4     2 ms     1 ms     2 ms  209.148.233.121
  5     2 ms     2 ms     2 ms  209.148.235.222
  6    13 ms    13 ms    20 ms  hosted-by.i3d.net [213.179.220.6]
  7    13 ms    13 ms    13 ms  cator1-rt002i.i3d.net [109.200.219.1]
  8    20 ms    20 ms    21 ms  casla1-rt001i.i3d.net [109.200.219.4]
  9    34 ms    34 ms    34 ms  camtr1-rt001i.i3d.net [109.200.218.79]
 10    34 ms    34 ms    34 ms  hosted-by.i3d.net [213.179.192.53]

Trace complete.

Pinging 142.250.31.139 with 56 bytes of data:
Reply from 142.250.31.139: bytes=56 time=39ms TTL=56
Reply from 142.250.31.139: bytes=56 time=39ms TTL=56
Reply from 142.250.31.139: bytes=56 time=40ms TTL=56
Reply from 142.250.31.139: bytes=56 time=40ms TTL=56
Reply from 142.250.31.139: bytes=56 time=39ms TTL=56

Ping statistics for 142.250.31.139:
    Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 39ms, Maximum = 40ms, Average = 39ms

For comparison, from Bell VDSL to i3d.net's Montreal server:

traceroute to 213.179.192.53 (213.179.192.53), 30 hops max, 60 byte packets
 1  64.230.11.156 (64.230.11.156)  4.808 ms  4.727 ms  4.707 ms
 2  64.230.104.164 (64.230.104.164)  5.528 ms  5.939 ms  5.923 ms
 3  cr02-toroon12xfw-bundle-ether7.net.bell.ca (142.124.127.197)  5.389 ms  5.372 ms  5.356 ms
 4  cr02-toroonxnhrz-bundle-ether1.net.bell.ca (142.124.127.209)  4.501 ms  6.882 ms  6.867 ms
 5  cr02-toroonxnhrz_bundle-ether11.net.bell.ca (142.124.126.223)  4.426 ms  4.408 ms  5.132 ms
 6  ae63.bar4.toronto1.level3.net (4.1.114.169)  6.717 ms  4.710 ms  4.689 ms
 7  ae1.11.bear1.Montreal2.level3.net (4.69.203.133)  11.825 ms  12.276 ms  11.772 ms
 8  4.15.16.6 (4.15.16.6)  11.711 ms  21.618 ms  21.588 ms
 9  hosted-by.i3d.net (213.179.192.53)  11.647 ms  11.645 ms  11.627 ms

PING 213.179.192.53 (213.179.192.53): 56 data bytes
64 bytes from 213.179.192.53: seq=0 ttl=57 time=11.967 ms
64 bytes from 213.179.192.53: seq=1 ttl=57 time=11.916 ms
64 bytes from 213.179.192.53: seq=2 ttl=57 time=11.674 ms
64 bytes from 213.179.192.53: seq=3 ttl=57 time=11.899 ms
64 bytes from 213.179.192.53: seq=4 ttl=57 time=14.229 ms

--- 213.179.192.53 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 11.674/12.337/14.229 ms

From Rogers Fiber to Google DNS:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  OPN100 [192.168.0.1]
  2     1 ms     1 ms     1 ms  173.33.156.1
  3     1 ms     1 ms     1 ms  209.148.230.57
  4     2 ms     2 ms     1 ms  209.148.233.121
  5     2 ms     2 ms     2 ms  209.148.235.222
  6     *        *        *     Request timed out.
  7    15 ms    15 ms    15 ms  74.125.244.161
  8    16 ms    16 ms    16 ms  216.239.41.175
  9    15 ms    14 ms    15 ms  dns.google [8.8.8.8]

Trace complete.

Pinging 8.8.8.8 with 56 bytes of data:
Reply from 8.8.8.8: bytes=56 time=14ms TTL=116
Reply from 8.8.8.8: bytes=56 time=14ms TTL=116
Reply from 8.8.8.8: bytes=56 time=15ms TTL=116
Reply from 8.8.8.8: bytes=56 time=15ms TTL=116
Reply from 8.8.8.8: bytes=56 time=14ms TTL=116

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

 For comparison, Bell VDSL to Google DNS:

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  64.230.11.156 (64.230.11.156)  4.830 ms  4.760 ms  5.333 ms
 2  64.230.104.164 (64.230.104.164)  6.626 ms  6.608 ms  6.591 ms
 3  cr02-toroon12xfw-bundle-ether7.net.bell.ca (142.124.127.197)  5.714 ms  5.694 ms  5.676 ms
 4  cr02-toroonxnhrz-bundle-ether1.net.bell.ca (142.124.127.209)  5.671 ms  5.652 ms  6.361 ms
 5  64.230.97.147 (64.230.97.147)  5.053 ms  5.035 ms  5.505 ms
 6  google_bx3-torontoxn.net.bell.ca (184.150.181.147)  4.947 ms  9.575 ms  9.562 ms
 7  74.125.244.145 (74.125.244.145)  5.844 ms 108.170.250.241 (108.170.250.241)  5.779 ms 74.125.244.161 (74.125.244.161)  4.983 ms
 8  216.239.41.175 (216.239.41.175)  5.781 ms 216.239.50.119 (216.239.50.119)  4.909 ms 216.239.49.189 (216.239.49.189)  4.851 ms
 9  dns.google (8.8.8.8)  4.888 ms  4.865 ms  4.859 ms

PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=0 ttl=118 time=4.677 ms
64 bytes from 8.8.8.8: seq=1 ttl=118 time=4.990 ms
64 bytes from 8.8.8.8: seq=2 ttl=118 time=4.834 ms
64 bytes from 8.8.8.8: seq=3 ttl=118 time=5.921 ms
64 bytes from 8.8.8.8: seq=4 ttl=118 time=4.939 ms

--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max = 4.677/5.072/5.921 ms

Once you take into account the VDSL's first hop is 5ms compared to the <1ms for Fiber the difference is laughable.

Rogers Fiber to Google DNS via IPv6:

Tracing route to dns.google [2001:4860:4860::8888]
over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  OPN100 [2607:fea8:fd10:7edf:5a9c:fcff:fe10:ffe6]
  2     1 ms    <1 ms    <1 ms  2001:506:20:7fc0:0:2091:4825:5065
  3     1 ms     1 ms     1 ms  2607:f798:10:187b:0:2091:4823:57
  4     2 ms     2 ms     1 ms  2607:f798:10:3b6:0:2091:4823:7077
  5     2 ms     2 ms     2 ms  2607:f798:10:35c:0:2091:4823:5222
  6     2 ms     2 ms     2 ms  2607:f798:14:83::2
  7     2 ms     2 ms     2 ms  2001:4860:0:11d6::1
  8     2 ms     2 ms     2 ms  2001:4860:0:1::31e1
  9     2 ms     2 ms     2 ms  dns.google [2001:4860:4860::8888]

Trace complete.

Pinging 2001:4860:4860::8888 with 56 bytes of data:
Reply from 2001:4860:4860::8888: time=2ms
Reply from 2001:4860:4860::8888: time=2ms
Reply from 2001:4860:4860::8888: time=2ms
Reply from 2001:4860:4860::8888: time=2ms
Reply from 2001:4860:4860::8888: time=2ms

Ping statistics for 2001:4860:4860::8888:
    Packets: Sent = 5, Received = 5, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 2ms, Maximum = 2ms, Average = 2ms

I am suspicious 209.148.235.222 is a problem on IPv4. Two other Rogers customers provided data to me. One Rogers fiber customer that goes through 209.148.235.222 also showed unusual latency to similar servers that I tested. Another customer on Rogers coax, that does not go through 209.148.235.222, did not show these issues and appeared to have latency on par with the IPv6 tests (after the first hop of coax).

I can only hope Rogers does not consider this normal and ignore it. This is suppose to be Roger's fastest and most expensive internet service ever and it being laughed at by the latency that Bell and independent ISPs, like Teksavvy, can provide on ancient DSL copper.

[RogersCorey]

Thank you for doing these tests @roytoy.

I understand that you are using latency sensitive applications but these ping times are all well within our tolerance levels.

As I mentioned previously, we need to see ping times in excess of 100ms before we'll be able to perform a successful escalation.

Please try performing a 500 packet ping test from your Command Prompt to see if we can capture ping times in excess of 100ms.

Regards,

RogersCorey

[FraggleRocker]

I have the exact same issue since switching. I play a lot of League of Legends and I play at a very high level and I make a fair chunk of money on the side streaming, so I need the best ping possible. While using Teksavvy I had a consistent 21-25ms ping which was fantastic, but when a Rogers rep came to my door offering a price I couldn't refuse, I assumed I'd be getting a better service considering Rogers sells internet to Teksavvy so how could my internet possibly be slower from the distributor? But instead I now have double the ping to that server and I'm averaging between 39-46ms, which is a significant difference. I have on occasion been as low as 28ms, but that was for a single day.

I'm honestly really disappointed thus far in Rogers and the internet they provide and am considering paying significantly more to go back to Teksavvy if it means I can reduce my ping and continue to play competitively.

[RogersYasmine]

Hello @roytoy ,

Thanks for chiming in and sharing your personal experience with the community! I can certainly understand how packet loss would be a huge downer for a gamer, like yourself. We certainly want to provide the best possible experience for you when using our services. 

We will need a bit more data from you in order to better pinpoint what is happening. If possible, can you please follow the steps provided here and provide us with your results? 

We look forward to hearing back from you soon! 

RogersYasmine

[-G-]

@FraggleRocker When you were with Teksavvy, were you a DSL customer or Cable Internet?  If you were a DSL customer, a DOCSIS-based Internet service can easily add 20 ms to your ping RTT.  If you were previously a cable Internet customer, it's also quite likely that Teksavvy had different peering arrangements which provided better connectivity to your gaming servers.

[Bdor]

I've been having this exact same issue and it's been persisting for me for a while now. Disappointed to say the least...

[YoungSinatra1]

[YoungSinatra1]

i also have terrible lag issues with rogers

[RogersZia]

Good evening and welcome to the Community @YoungSinatra1,

I know how frustrating it can be to use the Internet with latency issues. We will be happy to assist you. Please refer to our Knowledge Base article Troubleshooting Latency (Wired Devices) and post the results in this thread.

RogersZia