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.
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.
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).
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
(incl. VAT)
Buy Linux Magazine
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.
News
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.
-
Linux Usage Increases in Two Key Areas
If market share is your thing, you'll be happy to know that Linux is on the rise in two areas that, if they keep climbing, could have serious meaning for Linux's future.
-
Vulnerability Discovered in xz Libraries
An urgent alert for Fedora 40 has been posted and users should pay attention.
-
Canonical Bumps LTS Support to 12 years
If you're worried that your Ubuntu LTS release won't be supported long enough to last, Canonical has a surprise for you in the form of 12 years of security coverage.
-
Fedora 40 Beta Released Soon
With the official release of Fedora 40 coming in April, it's almost time to download the beta and see what's new.
-
New Pentesting Distribution to Compete with Kali Linux
SnoopGod is now available for your testing needs