Candlepin & Netem

Simulation of delay and delay jitter

Author: Jiří Hnídek /

Testing environment

  • We will need two VMs for running client and server
    • Subscription-manager
    • Candlepin server
  • We will also need separate network used only for communication between these two VMs

Create new network

  • Start: virt-manager
  • Go to: "Edit -> Connection Details"
  • Click at "+" in "Virtual Networks"
virt-manager: create new network

Setup new network

  • Wizard has 4 pages
    1. Give your network some unique name
    2. Configuration of IPv4 (you can use default values, but make sure network is not already in use)
    3. Configuration of IPv6 (you can enable it and use e.g. fd00:dead:beef:55::/64, enable DHCPv6 in this case too)
    4. Select "Isolated virtual network" and "Enable IPv6 internal routing/networking"

Use new network

  • Make sure VM (client) is not running
  • Open preferences of selected VM
  • Click on: "Add Hardware"
  • Select: "Network"
    • Change "Network source" to your new network created by wizard.
    • There is no need to change other options
  • Repeat previous steps for server too

Testing and final tweaking

  • Start VMs login there and make sure new network interface is active and IP address(es) were assigned to it
  • Try to ping from client to server and vica verse
  • Modify /etc/hosts to simplify your further work

Traffic Control

  • It can be used for shaping and scheduling of traffic
  • Routers are usually responsible for this (fast, hardware)
  • We can traffic control in Linux too using command: tc

Traffic Control and some terminology

  • Traffic Control in Linux can be assembled from "qdisc" (queuing disciple)
  • We can simply imagine qdisc as FIFO or queue
  • Qdisc can be classfull (usually used for scheduling) or it can be classless (usually used for shaping)

Netem and TBF

  • Traffic Controll can be also used for simulation of condition of real network
  • Qdisc called Netem can be used for simulating of delay, delay jitter, packet loss, corrupting of packets, etc.
  • TBF (token bucket filter) can be used for scaling down of bandwidth

   +---+---+---+-------        +---+---+---+---+---+--------
   |   |   |   |               |   |   |   |   |   |
<--+   | Netem |<--------------+   |   |  TBF  |   |<----
   |   |   |   |               |   |   |   |   |   |
   +---+---+---+-------        +---+---+---+---+---+--------

Linux Traffic Control

  • For our purpose we can use only netem for simulation of delay and delay jitter
  • To list existing traffic control used at specific network inteface:
  • $ tc -s -d qdisc show dev eth0

Queue Length

  • To get length of all queues we need to use another command:
  • $ ip link list
  • We can set new length of queue using following command:
  • $ ip link set dev eth0 txqueuelen 100


  • To replace default qdisc with netem we have to use following command:
  • $ tc qdisc add dev eth0 parent root handle 1:0 netem delay 100ms
  • We can try to use ping, but we will get constant delay. To get more realistic result we need to set also delay jitter using following command:
  • $ tc qdisc change dev eth0 parent root handle 1:0 \
    netem delay 100ms 10ms 25%
  • We will need to set same qdisc on server and client

Delay matters

Subman and Delay

  • We can test delay using subscription-manager and curl command
  • $ time subscription-manager version
  • We can mimic recreating of TCP connection using following command:
  • $ time curl -k -u admin:admin "https://candle:8443/candlepin/"; \
      time curl -k -u admin:admin "https://candle:8443/candlepin/status"

Proposed improvements

  • If TCP connection was reused between REST API call, then result time would be twice smaller:
  • $ time curl -k -u admin:admin "https://candle:8443/candlepin/" \
  • We could go even better, when HTTP/2 was used:
  • $ curl -k -u admin:admin "https://candle:8443/candlepin/" & \
      curl -k -u admin:admin "https://candle:8443/candlepin/status"

That's all Folks!