I noticed that when providing "latency" instead of "limit", tc utility
adds burst size to the token buket's queue limit (q_tbf.c, line 215):
lim = rate64*(double)latency/TIME_UNITS_PER_SEC + buffer;
This results in a bigger buffer than expected, yielding latency higher
than requested.
To show that the achieved latency is higher than expected, I
configured 10kbps with 10kb burst and 1 second latency, and sent 30kb
instantanously.
(network configuration: host1----switch----host2)
switch: tc qdisc add dev s1-eth2 root tbf rate 10kbps burst 10kb latency 1s
host1: ping host2 -s 1500 -l 20
PING 10.0.0.2 (10.0.0.2) 1500(1528) bytes of data.
1508 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=0.287 ms
1508 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=0.018 ms
1508 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=0.007 ms
1508 bytes from 10.0.0.2: icmp_seq=4 ttl=64 time=0.007 ms
1508 bytes from 10.0.0.2: icmp_seq=5 ttl=64 time=0.006 ms
1508 bytes from 10.0.0.2: icmp_seq=6 ttl=64 time=0.006 ms
1508 bytes from 10.0.0.2: icmp_seq=7 ttl=64 time=78.6 ms
1508 bytes from 10.0.0.2: icmp_seq=8 ttl=64 time=236 ms
1508 bytes from 10.0.0.2: icmp_seq=9 ttl=64 time=393 ms
1508 bytes from 10.0.0.2: icmp_seq=10 ttl=64 time=551 ms
1508 bytes from 10.0.0.2: icmp_seq=11 ttl=64 time=709 ms
1508 bytes from 10.0.0.2: icmp_seq=12 ttl=64 time=867 ms
1508 bytes from 10.0.0.2: icmp_seq=13 ttl=64 time=1024 ms
1508 bytes from 10.0.0.2: icmp_seq=14 ttl=64 time=1181 ms
1508 bytes from 10.0.0.2: icmp_seq=15 ttl=64 time=1339 ms
1508 bytes from 10.0.0.2: icmp_seq=16 ttl=64 time=1497 ms
1508 bytes from 10.0.0.2: icmp_seq=17 ttl=64 time=1655 ms
1508 bytes from 10.0.0.2: icmp_seq=18 ttl=64 time=1812 ms
1508 bytes from 10.0.0.2: icmp_seq=21 ttl=64 time=982 ms
1508 bytes from 10.0.0.2: icmp_seq=22 ttl=64 time=140 ms
1508 bytes from 10.0.0.2: icmp_seq=23 ttl=64 time=0.057 ms
^C
--- 10.0.0.2 ping statistics ---
23 packets transmitted, 21 received, 8% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.006/593.931/1812.417/611.926 ms, pipe 20
As you can see in icmp #18 - the latency peaked at 1.8 seconds even
though i requested 1 second max.
Proposed solution:
I think that burst size should not be added to the lim parameter
(q_tbf.c, line 215):
lim = rate64*(double)latency/TIME_UNITS_PER_SEC;
Is this sensible?
