Pings/jitter

Doing a ping test using cmd, is some variation in pings expected on an idle network? I get mostly 38ms pings, but occasionally get the odd one in the mid 40s or 50s even though im not using the connection. So should all the pings be the same if im not using my connection, or is some variation expected?

Edited by bobble_bob (Wed 13-May-15 17:05:35)

They will all be different and there are many factors. Destination, Destination device load, Routing, Routing Changes, Route usage, load/activity at every node/switch, what your PC is doing, priority of ping and other processes ...

Ah right so even if i ping the same address for 2 mins to test (used ping bbc.co.uk -n 120) command, its normal to still get some variation?

Also to add my ISP prioritize traffic at peak times. Would this mean pings could potentially be delayed and give a false reading?

Edited by bobble_bob (Wed 13-May-15 18:00:02)

Yes. If nothing is heavily loaded, no congestion and no dynamic routing changes then you will still see a variation albeit small. Say if you are in the North of Scotland and ping a server in London, you may see 40ms typical with possibly excursions to 38 and 42 (for example). If traffic is prioritised and the network is loaded, you could see it increase to 50 or more.

If one is delayed, it is NOT a false reading as it is demonstrating actual conditions.

PING tests should only be used as "indicative" and to prove a connection is reacable.

Cheers thanks for the help

It also relies on the thing your pinging actually thinking your pings are important to respond to. If it has better things to do then it most likely will ignore your pings for a bit.

Maybe its that then. Just seemed odd that i would get very constant pings (38-40ms), but then the odd one in the 50s or 90s for no reason, then back to normal

Get yourself a copy of PingPlotter - older versions are free.

It actually runs a Trace Route (tracert) function whereby it pings the target device with the TTL parameter set to 1. That means it will be responded to by the first device it meets. It then sends a ping with TTL=2 which reaches the second device and so on until it reaches the ultimate target.


You will see a graph of Ping times for each node on the route and they will settle with an average time, however every now and again one may suddenly jump to hundreds of milliseconds whilst everything else is responding normally.

It is quite possible to have the average time for an intermediate node higher than that of a target - it shows that messages going through are given higher priority than responding to the ping command - which is correct.

Have a play with it and you will end up with a better understanding of "ping" and why it is an indicative value and not set in stone.

Cheers. Guess at the end of the day there isnt much you can do about pings. If the many nodes you're going through on the way to the destination decide to give the ping a low priority for whatever reason, then it will show on your graph as a high ping

Think of the road network.

To paraphrase-
"
Just seemed odd that i would get very constant travelling times to work (38-40 minutes), but then the odd one in the 50 minutes or 90 minutes for no (obvious) reason, then back to normal
"
------------------

My normal time to our local airport is 30 minutes; but last year it took over 3 hours (missed the flight) - with no obvious reason.


Left home slightly earlier than usual, mid-morning so not rush-hour, normal route - dual-carriageway and motorway for 18 miles out of 20 miles, the delays started on motorway about 4 miles from the airport; and I was sitting in my car just beyond the end of the runway as my intended plane took off.

There were absolutely no signs as to the reason for the delays; and this was also confirmed by my newsagent the next day who happened to be travelling about the same time as myself.

Returning home on the opposite side about 30 minutes later, no signs of queues etc on that other carriageway.

In reply to a post by MHC:

Get yourself a copy of PingPlotter - older versions are free.

It actually runs a Trace Route (tracert) function whereby it pings the target device with the TTL parameter set to 1. That means it will be responded to by the first device it meets. It then sends a ping with TTL=2 which reaches the second device and so on until it reaches the ultimate target.


You will see a graph of Ping times for each node on the route and they will settle with an average time, however every now and again one may suddenly jump to hundreds of milliseconds whilst everything else is responding normally.

It is quite possible to have the average time for an intermediate node higher than that of a target - it shows that messages going through are given higher priority than responding to the ping command - which is correct.

Have a play with it and you will end up with a better understanding of "ping" and why it is an indicative value and not set in stone.

Just be sure to understand the results properly, I know of a case where someone was complaining quite loudly of spikes of 200MS and packetloss on the first hop even though they were actually getting a very nice 9ms to the destination and showing no packet loss to the actual final destination.

It was a nightmare trying to get them to understand that the router responded to pings at a very low priority and also responding to ping relies on the CPU where as the actual packet forwarding was being done by an ASIC

In reply to a post by bobble_bob:

Cheers. Guess at the end of the day there isnt much you can do about pings. If the many nodes you're going through on the way to the destination decide to give the ping a low priority for whatever reason, then it will show on your graph as a high ping

In some devices the ping response is handled by the CPU which depending on the device capabilities may exist purely for the control plane and since it's job is effectively to allow management access to its often a pretty low end component.

You should only really worry about the loss/response if it appears to be also affecting subsequent hops

Using wired connection to the router I would hope as wireless will give fluctuations.

A quality response (from the bbc.co.uk) would be steady ie a steady 20ms or a steady 60ms.

A poor response would be fluctuations ie 25ms rising to 60ms and dropping again. Makes no difference for web browsing but for gaming it can be an issue.