1

Apparently NETEM uses tfifo, which queues packets based on time to sent. This results in jitter causing packet reorder. For example the following line will cause packet reordering*:

tc qdisc add dev eth0 root handle 1: netem delay 10ms 100ms

NETEM manual suggests if you don't want reordering, then replace the internal queue discipline tfifo with a pure packet fifo (pfifo), and gives the following example too add lots of jitter without reordering:

tc qdisc add dev eth0 root handle 1: netem delay 10ms 100ms
tc qdisc add dev eth0 parent 1:1 pfifo limit 1000

But it doesn't work! Packets still get reordered! (and it looks like it's kernel dependent according to this)

So, does anyone know how to add jitter WITHOUT reordering packets?

kakhkAtion
  • 2,264
  • 22
  • 23

2 Answers2

1

One hacky option is to use constant delay (no jitter) and have a loop and change the delay value in the loop.

Say you want a 50ms delay with 5ms variance. You first add the base delay:

tc qdisc add dev eth0 root handle 1: netem delay 50ms

And can the have a loop that picks a random delay between 45ms and 55ms and change the delay as below:

tc qdisc change dev eth0 root handle 1: netem delay 53ms

There are two things to keep in mind though:

1- It takes some ticks to change the delay. I found a sleep of 0.1s in the loop is reasonable. So this means your limited by the jitter frequency.

2- When you decrease the delay, new packets get queued with a smaller delay (i.e. earlier send time) than packets already in the queue, which can cause reordering! You can mitigate this by decreasing the delay in a few steps, if the decrease is significant.

kakhkAtion
  • 2,264
  • 22
  • 23
0

In my case (Linux 4.17), I got the same ofo issue if the variance > mean. By setting the variance < mean, ofo does not happen any more. Of course you still need to use the pfifo qdisc:

tc qdisc add dev ethBr2   root handle 1:0    netem delay 50ms 40ms 25%
tc qdisc add dev ethBr2   parent 1:1         pfifo limit 1000
Trần Việt Hoàng
  • 537
  • 6
  • 16