Nick Buraglio

The Value of Measurements: Network Latency

Nick Buraglio

3 min read

0 You have liked this article 0 times.

There is no shortage of network telemetry data that can be collected, recorded, graphed, and stored for cross reference and triage. Not one to be underestimated, latency data can be incredibly powerful when leveraged for baseline and deviation notification.

As I have alluded to in the past, there are many tools in this space — you can read about some that I’ve written about in detail. Regardless of the tool, the data itself is powerful and the instrumentation it provides will only serve to make your network more robust and easier to work on.

One tool that is particularly easy to set up and use is smokeping, which provides:

  • Best of breed latency visualisations
  • Interactive graph explorers
  • Wide range of latency measurement plugins
  • Master/Slave System for distributed measurements
  • A highly configurable alerting system
  • Live latency charts with the most ‘interesting’ graphs
  • Free and open source software written in Perl by Tobi Oetiker, the creator of MRTG and RRDtool

Why do I need to track latency?

Latency data is incredibly powerful and can be an indicator of anything from a failing optic to a network compromise.

It is especially useful for small- to medium-sized ISPs (and especially WISPs), where the cost of software and operational overhead is at a premium, and customer satisfaction is the currency that is dealt. One time, I was able to use smokeping to help diagnose a functional denial of service of a commonly deployed cable CPE, as detailed here.

Figure 1: From measuring my home network latency I was able to see an outage on 23 April to my operator

I can’t emphasise enough how useful long term trend data is. Smokeping can be used to monitor more than just ping RTT, it supports a myriad of plugins allowing for application latency of protocols such as DNS queries, http get, ssh daemon response, and speed test results, to  name a few.

Where smokeping is particularly useful is in simulating customer experience. As with most things in life, perspective is paramount. To address this, smokeping can also be deployed as a distributed model.

Deploying it with installations more local to a customer or in a far-flung site (say, on a raspberry pi) located in remote POP sites or pedestal locations will provide a closer perspective to what the customer actually sees. In the past, I have deployed remote raspberry pi devices in an actual FTTH pedestal connected to an ONT to provide the exact customer point of view and it delivered a wealth of information I would not otherwise be able to see.

There are a myriad of different installation guides for smokeping — my recommended starting point is by Gerd Naschenweng. It provides a Docker instance but also has a very good set of configuration files from which to build examples.

For anyone interested in seeing a working smokeping installation, mine is public and available to view. It provides a few things such as DNS latency, RTT for IPv4 and IPv6, RTT for ZeroTier hosts and RIPE Atlas probes — it’s a powerful toolkit. Check it out here and let me know your thoughts on smokeping below.


This article was originally published at the APNIC blog.

0 You have liked this article 0 times.

About the author

Nick Buraglio has been involved in the networking industry in varying roles since 1997 and currently works on the network planning and architecture team for a major international research network provider. Prior to his current role, Nick was employed by the University of Illinois as the Lead Network Engineer working on research and HPC, campus and wide area connectivity. In this role, Nick also functioned as the Lead Network Engineer and IP architect for the National Association of Telecommunications Officers and Advisors (NATOA) broadband project of the year, UC2B. Nick has also held Network Engineering positions at early regional broadband internet providers as well as at the National Center for Supercomputing Applications. Nick has participated in the SCinet working group on many occasions since 2002 ranging in roles from Security to Routing and has been involved in R&E, high performance networking, and security for the last 15 years. In addition to Network Engineering positions, Nick has been involved in cyber security from the campus, enterprise, and service provider perspective, and has been a trainer for the Federal Bureau of Investigation RCAT team. Nick has also been involved numerous production and experimental software defined networking projects over the last 8 years. Nick specializes in service provider backbone networks but also dabbles in broadband technologies, instrumentation, monitoring, data centers, Linux, and everything in between. His personal blog is at and is full of esoteric ramblings and strong opinions.

Comments 0