We are JitterWorks. So it makes sense to dig into the significance of jitter and the importance of tracking jitter trends. Last week, we gave you a spoiler when we said “we won’t go into traceroutes and hops in this blog.”

It’s a week later so, we will get into traceroutes and hops in this blog. A traceroute command from a network performance monitoring system like JitterWorks, does exactly what you’d think. It traces the route that traffic takes across the Internet. We’ve discussed speed tests and how they track latency and throughput. We can see when high latency occurs. A traceroute can pinpoint where latency and jitter occurs in the journey across the Internet – the eight hops it takes to get from source to destination.

The spreadsheet data below represents two traceroutes from two different clients using two different Internet Service Providers. Both sets of data show acceptable latency (columns 1-2). We’re going to concentrate on the last column. The standard deviation in latency along the journey. This number represents jitter.

In this spreadsheet, the latency numbers are great and the standard deviation numbers are, well, as you can see, terrific. No jitter!  (Side note, we are using real data from real clients so we x’d out the actual IP addresses of the routers in the hops). 

  1.|– gateway               0.8     0.9     0.0

  2.|– xx.xx.xx.xx           2.5     2.9     0.0

  3.|– xx.xx.xx.xx         12.8   13.0     0.0 

  4.|– xx.xx.xx.xx         17.7   17.9     0.0 

  5.|– xx.xx.xx.xx         18.4   22.4     1.5

  6.|– xx.xx.xx.xx         18.8   19.2     0.0

  7.|– xx.xx.xx.xx         17.3   17.6     0.0

  8.|– dns.google        17.7    18.1    0.0

This is a traceroute for the client we mentioned in last week’s blog who was experiencing heavy jitter during business hours. Though the latency numbers are good, you can see that the high standard deviation starting in hop two is causing an unacceptable amount of jitter.

  1.|– gateway               1.2     1.4     0.0

  2.|– xx.xx.xx.xx           6.2   32.9     9.1

  3.|– xx.xx.xx.xx         16.3   34.8     6.5 

  4.|– xx.xx.xx.xx         23.8   39.6     8.5 

  5.|– xx.xx.xx.xx         22.2   44.8     8.0

  6.|– xx.xx.xx.xx         24.2   44.1     9.6

  7.|– xx.xx.xx.xx         19.5   25.7     2.2

  8.|– dns.google         18.9   21.0    0.7

So what does all this mean? Armed with this information, the client’s IT consultant contacted their ISP and gave them a roadmap to where the jitter problems started to occur (hop 2). In this instance, the ISP did the right thing and re-routed Internet traffic coming from this company. The result was less jitter during business hours.

Moral of the story? It’s the same as most of our blogs. The more information you have regarding your network performance, the quicker and easier it is to address and resolve network problems.