How-To

Replicating Slow Latency on Linux

In demonstrating some monitoring software, Tom needed to replicate a slow network that was being used in a VDI environment. Here's how he did it.

• By Tom Fenton
• 12/02/2021

I recently found that, in order to demonstrate some monitoring software, I needed to replicate a slow network that was being used in a VDI environment. Using the Linux Traffic Control (tc) command, which is found on most modern Linux systems, I was able to easily accomplish this. I used it on a virtual machine (VM), but I have also used it on physical systems with the same results.

In two previous articles, I showed you how I installed Ubuntu on older equipment and on a virtual machine (VM), and then how I installed the VMware Horizon Client on it and was able to use it to connect to a Horizon desktop. I decided to focus on this topic as I have found that, due to the current chip shortage, many people are having to repurpose older systems because they simply cannot find new devices to use to attach to remote desktops.

I logged into my Linux system and was able to launch the Horizon Client and connect to a Horizon desktop without any issues.

Changing the latency
I work for ControlUp, and the purpose of this exercise was to demonstrate how Remote DX can display the latency between a client and a desktop. This primarily helps with diagnosing issues with end-users’ devices, though the information can be used for other things as well.

My initial connection to the system showed a connection to the router at 3ms, the virtual desktop at 179ms, and to a known good internet site (Google) at 18ms.

In order to change the latency, I used the tc command which can configure the Traffic Control feature that is built into the Linux kernel. Not only can you use it to inject latency and jitter into your network, you can also limit the bandwidth to a specific IP address. It is very powerful and I will only be using it in this example very simplistically.

You will need to know the name of your network interface. To get this, enter:

..lshw -C network

ip a

Mine was reported as ens192.

I first set it to slow the latency to all outgoing traffic to 200ms:

  tc qdisc add dev ens192 root netem delay 200ms  ## Set the delay
  tc -s qdisc show dev ens192 # Show the settings

When I pinged 8.8.8.8, it had a delay of an additional 200ms.

I cleared tc and slowed the latency to all outgoing traffic to 200ms, but let it vary by 125ms:

tc qdisc del dev ens192 root ## Clear the settings
tc qdisc add dev ens192 root netem delay 200ms  125ms ## Set the delay
tc -s qdisc show dev ens192 # Show the settings

When I pinged 8.8.8.8, it had a delay that varied wildly between 191 and 525ms. The 525ms was an outlier.

You don’t need to delay the traffic to everything; you can delay the latency to a specific IP address by using a tc filter:

    tc qdisc del dev ens192 root ## Clear clear the settings
    tc qdisc add dev ens192 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
    tc qdisc add dev ens192 parent 1:2 handle 20 netem delay 300ms
    tc filter add dev ens192 parent 1:0 protocol ip u32 match ip dst 8.8.8.8/32 flowid 1:2
    tc -s qdisc show dev ens192 # Show the settings
  

When I pinged 8.8.8.8, it had an additional 300ms of delay, but the other IP address that I pinged did not show additional latency.

In the example above, I just showed a very, very small example of the power of the tc command and just one of the things that it can do. While the Man page for it is quite extensive and may take some time to read and understand, this informative and is worth reading given the power of this command.

If you need an easy way to introduce latency into the network on a Linux machine the netem command can be very useful.