High-resolution network monitoring with ping

Cable Length

Different cable lengths can be revealed by run-time analysis. Data cables, whether made of copper or glass fibre, are always delay lines; signals cover around 20cm/ns. For the round trip time, the delay is about 10ns/m; the result is 0.5µs for a 50-meter cable. This latency is much less than you see through a gigabit switch and also occurs irrespective of packet size, but still within a measurable framework. Pinging every second can locate faults with an accuracy of about 50 meters based on daily averages. Figure 3 shows the network components in our lab at a glance.

Figure 3: Two small gigabit switches and a large gigabit switch (lower half) cause RTTs about 20µs longer; cable effects were: 500ns (blue 50-meter cable), 5ns (black 0.5-meter cable), and 0.2ns (4cm adapter) longer.

The values shown in Figure 4 clarify that the volatility of the daily average values is virtually the same as the additional latency caused by a 50-meter cable in place of a 0.5-meter cable. After two days, I replaced the 0.5-meter patch cable with a 50-meter cable that theoretically increases the RTT by 0.5µs.

Figure 4: A 50-meter Ethernet cable is noticeable as a peak in the RTT curve.

The 49.5 extra meters of cable therefore evidently caused an RTT increase of 0.5µs. For the first two days with a 0.5-meter cable, the average RTT was 172.877µs; for the last two days with a 50-meter cable, RTT increased to 173.562µs – 685ns more.

Daily average values vary significantly because of inconsistent utilization of computers and dozens of programs, such as Tor, I2P, KTorrent, GNUnet, Squid 3, DHCP, NTP, Kaffeine, and Firefox. Detecting such small RTT changes requires averaging several daily mean values with only one ping a second.

Because an Ethernet segment (collision domain) must be less than 100 meters in length – and usually significantly shorter segments are used – at least 100-meter resolution is easily achievable in practice with 1,000-second averages.

In the Air

WiFi measurements are in principle just as feasible as measurements on a gigabit LAN. However, the majority of WiFi routers and devices automatically controls the data rate (bandwidth), so the RTT varies accordingly. Most routers cannot turn this off, and many do not even show you the data rate. On Linux, admins can set the data rate for WiFi with

iwcofig wlan4 rate 24M fixed

although it doesn't change the router rate. Curious admins have nothing left to do but make sure the rate displayed by the router remains constant during measuring.

A second difference from measuring LANs is the signal speed, which is 50 percent higher than on the wire, at around 30cm/ns. The value I measured for 1,000-second averages at 0.7 meters distance and with two 30dB attenuators was 0.985108ms; at a distance of 2.5km this was significantly higher at 1.023676µs, an increase of 38.6ms (Figure 5).

Figure 5: RTT measurement: a 50cm Yagi antenna pointed at a WiFi router next to a flashing headlight (arrow) 2.5km distant.

Theoretically, the difference should be only 16.7µs (i.e., far less than the gigabit LAN). However, some other factors seem to be present, such as rate fluctuations not displayed by the router or temperature differences: -2°C (28°F) across the 2.5km distance and 20°C (68°F) across 0.7 meters distance.

I also tested whether I could take these measurements with a Linux PC instead of a WiFi router using ad hoc mode. I was able to set both transmission rates, but contrary to expectations, the fluctuations were four times greater than pinging the wireless router.

Faster Measurements

If you can or want only to perform short measurements, you can adjust the Pinger program to send many pings per second instead of just a single ping. To do this, you only need to set a smaller time grid in the source code (e.g., 1ms for an accuracy that is greater by a factor of 32), and you need to use more threads. Because the threads times have a resolution of 1µs, there is not much to change.

In addition to the approach of using pings to determine latency, it is also possible to evaluate timestamps. TSF timestamps are suitable for this purpose on WiFi networks because they have a resolution of 1µs and are even free of jitter. However, not every hardware platform is suitable [7] for this.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Programming Snapshot – Go Network Diagnostics

    Why is the WiFi not working? Instead of always typing the same steps to diagnose the problem, Mike Schilli writes a tool in Go that puts the wireless network through its paces and helps isolate the cause.

  • Security Lessons: Bufferbloat

    An abundance of buffers hides the Internet’s dirty little secret.

  • Zing

    Zing is a lightweight, zero-packet network utility similar to ping that provides ping functionality without the payload.

  • Command Line: Network Diagnostic Tools

    Linux has the right tools to track down network errors and open the way for data packets.

  • Charly's Column

    If you do not receive a response to a ping, or if the response is seriously delayed, you might like to take this as a warning. But who wants to ping all day? You need a ping-based monitoring utility like Smokeping.

comments powered by Disqus
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.

Learn More

News