@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.
@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.
@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.
@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.
@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.
@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.
@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.
@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.
-
205414 views
-
156 Likes
-
-
