[netem] Incorrect jitter delays

[Lastique]

If I configure a netem rule with a delay and jitter, the actual network delay jitter is significantly different from the configured value.

With no netem rules:

$ ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=3.06 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=2.88 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=3.01 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=2.86 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=2.94 ms

With netem rule with delay and jitter:

$ sudo tc qdisc add dev wlp4s0 root netem delay 100ms 40ms

$ ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=106 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=111 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=115 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=124 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=136 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=120 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=4371 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=1487 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=5513 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=457 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=137 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=4367 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=111 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=4366 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=4378 ms
64 bytes from 192.168.1.2: icmp_seq=18 ttl=64 time=132 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=4373 ms
64 bytes from 192.168.1.2: icmp_seq=21 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=4375 ms
64 bytes from 192.168.1.2: icmp_seq=23 ttl=64 time=112 ms
64 bytes from 192.168.1.2: icmp_seq=19 ttl=64 time=4502 ms

Delays >4 seconds are unexpected, the expected delays are approximately 60 - 140 ms.

With netem rule with delay and *no* jitter:

$ sudo tc qdisc add dev wlp4s0 root netem delay 100ms

$ ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=102 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=103 ms
64 bytes from 192.168.1.2: icmp_seq=17 ttl=64 time=103 ms

In this case the delays are as expected.

The 192.168.1.2 host is a machine in the local network. The problem appears with different network interfaces, including loopback (in which case the delays are doubled) and on multiple machines.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: linux-image-4.15.0-29-generic 4.15.0-29.31
ProcVersionSignature: Ubuntu 4.15.0-29.31-generic 4.15.18
Uname: Linux 4.15.0-29-generic x86_64
NonfreeKernelModules: wl
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: lastique 2087 F.... pulseaudio
 /dev/snd/controlC1: lastique 2087 F.... pulseaudio
CurrentDesktop: KDE
Date: Thu Jul 26 19:31:25 2018
InstallationDate: Installed on 2013-10-11 (1748 days ago)
InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MachineType: ASUSTeK COMPUTER INC. N550JV
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-29-generic root=UUID=bafa6509-dea3-48a1-a308-129b1514ab28 ro quiet splash nmi_watchdog=0 acpi_osi= acpi_backlight=vendor
RelatedPackageVersions:
 linux-restricted-modules-4.15.0-29-generic N/A
 linux-backports-modules-4.15.0-29-generic N/A
 linux-firmware 1.173.1
SourcePackage: linux
UpgradeStatus: Upgraded to bionic on 2018-05-05 (82 days ago)
WifiSyslog:

dmi.bios.date: 11/19/2013
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: N550JV.208
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: N550JV
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrN550JV.208:bd11/19/2013:svnASUSTeKCOMPUTERINC.:pnN550JV:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnN550JV:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.family: N
dmi.product.name: N550JV
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.18 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.18-rc6

[Lastique (andysem)]

> Did this issue start happening after an update/upgrade? Was there a prior kernel version where you were not having this particular problem?

I don't know when this started to happen. But the same netem rules worked as expected in Ubuntu 17.10.

I've tested kernel version 4.18.0-041800rc6.201807221830, as you suggested. The problem does not appear with it:

$ ping 192.168.1.2
PING 192.168.1.2 (192.168.1.2) 56(84) bytes of data.
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=101 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=76.3 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=105 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=95.0 ms
64 bytes from 192.168.1.2: icmp_seq=5 ttl=64 time=128 ms
64 bytes from 192.168.1.2: icmp_seq=6 ttl=64 time=75.9 ms
64 bytes from 192.168.1.2: icmp_seq=7 ttl=64 time=84.5 ms
64 bytes from 192.168.1.2: icmp_seq=8 ttl=64 time=130 ms
64 bytes from 192.168.1.2: icmp_seq=9 ttl=64 time=94.6 ms
64 bytes from 192.168.1.2: icmp_seq=10 ttl=64 time=106 ms
64 bytes from 192.168.1.2: icmp_seq=11 ttl=64 time=76.2 ms
64 bytes from 192.168.1.2: icmp_seq=12 ttl=64 time=108 ms
64 bytes from 192.168.1.2: icmp_seq=13 ttl=64 time=118 ms
64 bytes from 192.168.1.2: icmp_seq=14 ttl=64 time=142 ms
64 bytes from 192.168.1.2: icmp_seq=15 ttl=64 time=96.5 ms
64 bytes from 192.168.1.2: icmp_seq=16 ttl=64 time=80.6 ms