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.