Please paste the results of a Ping (just the results without summaries, as shown by clicking here).
Just remember we are calculating ONLY the Jitter. Any packet loss is not calculated.

What is Jitter?
Well in short, Jitter is something that occurs during the transmission of data packets over a network. Each packet experiences a delay from point A to point B. During real-time and streaming transmissions, Jitter can cause a delay which can sometimes appear to be a frozen image, intermittent silence during a call, broken audio and/or video. Having Jitter is not a bad thing, but it's the variation in Jitter that can adversely affect your transmissions.

In networking, you can perform a ping to a destination and view the overall latency to that destination. But to understand that latency, it's important to know all of the factors bringing you from your source (point A) to your destination (point B). This is why it is important to perform a Ping. A Ping sends a message from point A to point B and awaits a return message. Any delay (latency) from the time of transmission to the time of response is measured. Jitter is the measurement of the difference (Δ time or delta time) between each return message from the Ping.

Understanding Ping
Once you perform your ping, you will receive results. In Windows (display may slightly vary), Linux, BSD and MacOS X (and above), you may see results with each line as:

64 bytes from 8.8.8.8: icmp_seq=1 ttl=250 time=18.6 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=250 time=20.1 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=250 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=250 time=22.0 ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=250 time=20.3 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=250 time=19.6 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=250 time=20.5 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=250 time=20.8 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=250 time=19.7 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=250 time=21.7 ms
--- 8.8.8.8 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 18.666/20.350/22.042/0.965 ms

The above Ping sent a message to 8.8.8.8 (Google's public DNS server) 10 times and received return messages. The "time" marked on each line is the amount of time it took for the message to make a round-trip from your computer to the remote computer and back.

Understanding Jitter
Having Jitter is not always bad. In fact, there are totally acceptable Jitter levels. However since Jitter measures the incosnsistencies of network transmissions, it is important to keep the Jitter levels as low as possible to maintain a good, steady data stream. After reviewing different types of Jitter, many analysts differ on what they consider acceptable. Many systems that are affected by Jitter use buffers to control them. For streaming media such as online video, Jitter buffers work well since they are not required to disseminate real-time data as in Voice over IP. However, Voice and Video over IP does require lower buffering and better network performance (lower Jitter).

Quality of Service (QoS) is one method to control the actual packet-level delays based on the type of traffic. Many switching and routing devices can read the packet headers of transmissions and determine if the packet requires real-time or not. It the packet is a real-time packet, the device will give it the highest priority if that is what the QoS is set for. It is important to understand that once the traffic has left your network and is being routed over another network (such as the Internet), QoS only works within your network. The idea of QoS on the Internet is difficult to consider since the Internet is comprised of many traffic types and providers cannot be expected to control every aspect of the flow of data. That would be against the ideology of Network Neutrality and limit the purpose of the Internet as a whole.

Since we are using a Ping to help determine our Jitter rate, we are measuring the Jitter between the source to the destination. This is to gather an overall understanding of Jitter between your network and a remote desitnation network. In this case, we can look at all of the above values and determine that their Jitter rates are acceptable.

Jitter Level     Acceptability
   <   1 ms      Excellent
   <   5 ms      Extremely Good
   <  20 ms      Very Good
   <  50 ms      Good
   <  80 ms      Good to Fair
   < 100 ms      Fair

64 bytes from 8.8.8.8: icmp_seq=1 ttl=250 time=  18.6  ms             Δ time
64 bytes from 8.8.8.8: icmp_seq=2 ttl=250 time=  20.1  ms               1.5  ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=250 time=  19.7  ms               0.4  ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=250 time=  22.0  ms               2.3  ms
64 bytes from 8.8.8.8: icmp_seq=5 ttl=250 time=  20.3  ms               1.7  ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=250 time=  19.6  ms               0.7  ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=250 time=  20.5  ms               0.9  ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=250 time=  20.8  ms               0.3  ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=250 time=  19.7  ms               1.1  ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=250 time= 21.7  ms               2.0  ms
                               Avg Latency:       6.77 ms Avg Jitter:   1.09 ms

So it does seem as the Jiter to our destination is actually Excellent and we should have no issues with real-time communications.