@teamlloyd You just inspired me to do an IPv6 test myself.
Windows: "ping -6 -n 3600 -w 20000 dns.google.com"
Ping statistics for 2001:4860:4860::8844:
Packets: Sent = 3600, Received = 3600, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 35ms, Average = 16ms
Test completed a few minutes ago. Same DAA/R-PHY node as the one in my previous post. However, the only Rogers hardware in the mix in my home is an XB8 in Bridge Mode. Router/firewall is my latest little science project.
IPv4 performance is comparable.
Ping statistics for 8.8.8.8:
Packets: Sent = 100, Received = 99, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 24ms, Average = 16ms
Packet loss is actual. Nothing I can do about it. The only thing that I can control is how well my hardware performs... and I think I can still make it go faster.
FYI, here are quick ping tests from this morning, taken at the start of the work day.
XB8 (bridge mode)
--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.539/26.738/202.596/4.699 ms
XB7 (gateway mode)
--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 999 packets received, 0.1% packet loss
round-trip min/avg/max/stddev = 17.008/31.569/60.928/6.445 ms
Higher latency, lots of jitter where the typical ping RTT constantly varies between 20 and 50 ms, and the occasional latency spike in the 100-200 ms range.
All I can say is that the current network performance, at its best, is what I would expect to see at its worst.
The good news is that in Markham, there will soon be a VERY disruptive competitive threat to all of the incumbents who have been resting on their laurels -- An independent is in the process of bringing FTTH to the entire city. (Last week, I saw their crews installing fibre along 16th Ave. and into some of the surrounding neighbourhoods.) I don't know how good their service will actually be but at something like $60/month for a 1 Gig symmetric Internet service and the ability to offer 10 Gig symmetric, they will get significant market capture.
There is absolutely NO way that Bell will ever be able to compete with DSL, so you know that they will accelerate their FTTH roll-out. (They are doing one neighbourhood now, right next to Markham-Stouffville Hospital.)
I don't know how Rogers will respond but in the not-too-distant future, they will have a very hard time competing with any DOCSIS-based offering. I can only hope that we will start to see some good things happening soon.
FYI, things seem to be getting better for me:
--- 8.8.8.8 ping statistics ---
1000 packets transmitted, 1000 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.299/16.904/28.090/2.300 ms
Welcome to the Rogers Community Forums!
I can understand how frustrating it is to deal with latency issues. We definitely want to help you get this investigated. Please provide us with a Ping Test and a Traceroute so we can try to determine where the latency is occurring. You can find the specific steps here.
Please post your results to the community so we can review.
RogersTony
For all of you troubleshooting latency, I first wanted to share my ping and traceroute to www.google.ca, just so you can see what thing should look like.
--- www.google.ca ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 13.116/16.706/26.050/2.290 ms
% traceroute www.google.ca
traceroute to www.google.ca (172.217.165.3), 64 hops max, 52 byte packets
1 [redacted].home.arpa (192.168.xxx.1) 0.734 ms 0.235 ms 0.230 ms
2 [redacted] (99.xxx.xxx.1) 27.593 ms 16.609 ms 18.805 ms
3 24.156.137.129 (24.156.137.129) 16.738 ms 16.547 ms 14.660 ms
4 3033-cgw01.ym.rmgt.net.rogers.com (209.148.232.73) 15.645 ms 14.444 ms 16.754 ms
5 209.148.235.218 (209.148.235.218) 15.685 ms 15.832 ms 16.568 ms
6 72.14.216.54 (72.14.216.54) 15.160 ms 15.776 ms 15.826 ms
7 74.125.244.145 (74.125.244.145) 74.218 ms
74.125.244.161 (74.125.244.161) 17.304 ms 14.597 ms
8 216.239.40.255 (216.239.40.255) 24.435 ms 16.247 ms
216.239.41.175 (216.239.41.175) 15.176 ms
9 yyz12s06-in-f3.1e100.net (172.217.165.3) 22.696 ms 15.852 ms 14.701 ms
The first thing to note is that in my (small, limited) ping test, the round trip time to www.google.ca was between 13 and 26 milliseconds. I had a bit of jitter but no serious latency spikes.
Traceroute (or tracert on Windows) is another interesting tool. I won't describe how it works here but between the computer in your home and the Internet host that you are trying to connect to, your traffic needs to pass through several hops, starting with your Ignite Gateway, the CMTS router (for Cable Internet customers), various hops through Rogers' internal network, then finally through an Internet Exchange Point (e.g. TorIX) beyond which, Rogers has no control. Each line in traceroute's output displays three measurements to each successive hop on the network path to the destination host.
Ideally, you want the round trip time (RTT) to each hop to be consistent.
Ideally, you want to see the RTT increase slightly to each successive hop on the network path. The times on "Hop 3" are the RTT's to the router at that hop, NOT the time between Hop 2 and Hop 3. If the times on Hop 3 are lower than those shown on Hop 2, it's an indication of jitter. If there is a lot of variation in the times shown on each hop, that's also an indication of jitter... and the cause could be ANY router or network link leading to that hop.
In my case, you can see that RTT on the first hop, the router/firewall in my home, is less than 1 ms. I'm running on my own network gear, with my Ignite Gateway in Bridge Mode. My in-home network is very fast. Anything past that is beyond my control.
You can see that the RTT times to Hop 2, the CMTS router, are 27.593 ms, 16.609 ms, and 18.805 ms. Note that this is VERY similar to what I see in my ping tests to www.google.ca, which means that pretty much ALL of the latency that I see to www.google.ca is being introduced between my Ignite Gateway the the CMTS router.
In my traceroute, note the latency spike of 74.218 ms shown on Hop 7. This hop is in Google's internal network but that latency could have been introduced anywhere on the network path up to that point.
For any of your test results, on your first hop (10.0.0.1 for Ignite Internet customers), I would expect to see round trip times of less than 10 ms. If you see RTTs of 150 ms, or huge variations, that is latency being introduced by your Ignite Gateway (or possibly your computer or your in-home network) before that traffic even gets out of your home.
If you see a lot of jitter or a non-response due to packet loss at Hop 2, that's an indication of congestion in your neighbourhood or your CMTS router.
If you are seeing a lot of latency and jitter in your ping tests to www.google.ca, I would open four terminal (or command line) windows/tabs and run simultaneous ping tests to 10.0.0.1 (your Ignite gateway), the IP addresses of Hops 2 and 3 on your traceroute to www.google.ca , and a ping test to www.google.ca. If you get a lot of variation just pinging your Ignite Gateway, that's bad. If the simultaneous ping test results to Hop 2 (your CMTS router) and www.google.ca are VERY similar, that's confirmation that the latency problem is caused by Rogers, very close to your home, and that localizes the cause to a combination of your Ignite Gateway, your local node, and your CMTS router.
Happy troubleshooting... and best of luck in getting your network performance issues resolved!
@teamlloyd can you go back into your post and delete all or most of the first address in the traces to google. That is your modem IP address which shouldn't be posted online in an open forum.
If you want to provide a trace which includes the modem address, use an IPv4 trace. Run:
tracert -4 www.google.com
That returns an IPv4 trace where the modem LAN address that shows up is 10.0.0.1, which is a normal address for the modem and doesn't point to the modem itself. The CMTS address is a tip off that you're on 1 of possibly 254 addresses connected to that CMTS.
Fwiw, to see the response time from the CMTS, which should be consistently in the 8 to 13 ms range, use the second hop address from the trace: 2607:f798:804:f8::1 Ping that address.
Run an extended ping test to determine the latency and packet loss to the CMTS. I usually run these for 24 hours.
@teamlloyd Have you tried logging into your Ignite Gateway, going to "Troubleshooting > Network Diagnostic Tools", and running a traceroute to 8.8.8.8? If you see times of 15 ms or less on all hops with no spikes, then that points to your Ignite Gateway introducing latency and jitter when forwarding packets from your internal LAN.
@Datalink wrote:
Fwiw, to see the response time from the CMTS, which should be consistently in the 8 to 13 ms range, use the second hop address from the trace: 2607:f798:804:f8::1 Ping that address.
The traceroute outputs got edited out but I recall seeing a 400+ ms response time from the (v)CMTS router.
Run an extended ping test to determine the latency and packet loss to the CMTS. I usually run these for 24 hours.
It's also critical to run any kind of network benchmarking on a system while it is completely idle and dedicated to preforming a test. Otherwise, you will see stuff like this:
Reply from 8.8.8.8: bytes=32 time=15ms TTL=118
Reply from 8.8.8.8: bytes=32 time=16ms TTL=118
Reply from 8.8.8.8: bytes=32 time=17ms TTL=118
Reply from 8.8.8.8: bytes=32 time=17ms TTL=118
Reply from 8.8.8.8: bytes=32 time=15ms TTL=118
Reply from 8.8.8.8: bytes=32 time=18ms TTL=118
Reply from 8.8.8.8: bytes=32 time=16ms TTL=118
Reply from 8.8.8.8: bytes=32 time=25ms TTL=118
Reply from 8.8.8.8: bytes=32 time=128ms TTL=118
Reply from 8.8.8.8: bytes=32 time=115ms TTL=118
Reply from 8.8.8.8: bytes=32 time=138ms TTL=118
Reply from 8.8.8.8: bytes=32 time=119ms TTL=118
Reply from 8.8.8.8: bytes=32 time=128ms TTL=118
Reply from 8.8.8.8: bytes=32 time=133ms TTL=118
Reply from 8.8.8.8: bytes=32 time=140ms TTL=118
Reply from 8.8.8.8: bytes=32 time=131ms TTL=118
Reply from 8.8.8.8: bytes=32 time=130ms TTL=118
Reply from 8.8.8.8: bytes=32 time=136ms TTL=118
Reply from 8.8.8.8: bytes=32 time=92ms TTL=118
Reply from 8.8.8.8: bytes=32 time=144ms TTL=118
Reply from 8.8.8.8: bytes=32 time=141ms TTL=118
Reply from 8.8.8.8: bytes=32 time=130ms TTL=118
Reply from 8.8.8.8: bytes=32 time=15ms TTL=118
Reply from 8.8.8.8: bytes=32 time=18ms TTL=118
Reply from 8.8.8.8: bytes=32 time=42ms TTL=118
Reply from 8.8.8.8: bytes=32 time=12ms TTL=118
Reply from 8.8.8.8: bytes=32 time=15ms TTL=118
Reply from 8.8.8.8: bytes=32 time=20ms TTL=118
Reply from 8.8.8.8: bytes=32 time=17ms TTL=118
Reply from 8.8.8.8: bytes=32 time=14ms TTL=118
That RTT spike was from me performing a speed test. I could do other things that would cause ping RTTs to spike to several-thousand milliseconds, especially when running the Ignite Gateway in "gateway" mode.
If your PC syncs to cloud storage or does anything else that is bandwidth-intensive, it will throw off ping tests and traceroute and other applications running on that system that are latency-sensitive.
Anyone who is running any type of ping test to benchmark the response or check on a response time due to suspected high latency has to be aware of what's running on their own system. If observed latency is such a problem, then the only item running on the test system should be a single ethernet connected pc or laptop. If necessary, disconnect everything else from the modem or router, ethernet or wifi, except for that single ethernet connected pc or laptop. That won't win any accolades from your family, but, it might be a necessary step to determine if the issue is really within your own network or due to external issues such as packet loss to the neighbourhood node or overloading at the CMTS.
With the introduction of the XBx modems, where everything goes thru the modem, testing for latency issues has become more difficult. As at @-G- points out, cloud storage or anything else that is bandwidth-intensive can affect your test results, so, you have to be aware of what's running on your system. You can learn what those affects are by running a ping test and starting something that is a normal activity on your system, including running a speed test, running an internet connected backup, watching a program in high def, etc, etc. That is all part of the learning curve. When you do enough testing, you'll get to a point where you can recognize high latency which is caused by something that you're doing, or something caused by an external issue. For the reasons listed above, you can't simply run a quick ping test and point to high latency as being caused solely by an external issue. Personal opinion, minimum test time should be at least an hour, preferably over 24 hours, with a time stamp. Without a time stamp, running a windows ping test is next to useless. You really need a time stamp to correlate high latency with any activities that might be running on your network, and to correlate high latency to time of day latencies seen at the neighbourhood node and CMTS. That brings up the issue of how to do this, which I will have to detail in another post.
Fwiw, running a 24 hour test will show the difference in latencies seen during high load times (early morning, late afternoon and into the evening) compared to the very early morning hours, 3 to 5 am, where the neighbourhood node and CMTS traffic reaches a minimum. With that early morning benchmark in hand, you'll know what's normal and what's very abnormal.
Good morning @ngehani!
If the area has been officially recognized as being congested, then you're on your way towards the solution.
We can check from your account to see where we are in the node segregation process and give you a better idea of the timeline if one is available. Feel free to send a private message to @CommunityHelps so we can assist you further. For more information on how our Private Messaging system works, you can find out more here.
Regards,
RogersCorey
-
21363 views
-
12 Likes
-
-
