Some tests for SQM and Buffbloat

I noticed that there was a lot of interest in SQM and buffbloat, and I did a simple test of how SQM works.
The buffbloat problem was not obvious in my network environment, so I set up the following test environment.
image

  1. As shown in the figure, three routers are cascaded through the LAN→WAN connection
  2. Run the iperf3 server on Router A
  3. In order to simulate network congestion, we limit the speed of the MAC address of the Test device on Router B. The lower the rate limit value is, the more obvious the effect will be.
  4. The Test device can open two consoles. One console can ping the gateway address of Router A and observe the ping latency, other console runs the iperf3 command.
  5. As can be seen, when iperf3 is running, the ping latency will rise sharply, as shown in the red box below, which proves that buffbloat exists on the network.

 
 
Now we need to configure qos policies to improve buffbloat. Execute the following script. I am using XE300, the WAN port is eth1, and set the rate to about 70% of the bandwidth.

tc qdisc replace dev eth1 root cake docsis ack-filter bandwidth 40kbps
ip link add name ifb4eth1 type ifb
tc qdisc del dev eth1 ingress
tc qdisc add dev eth1 handle ffff: ingress
tc qdisc del dev ifb4eth1 root
tc qdisc add dev ifb4eth1 root cake bandwidth 40kbps besteffort wash
ip link set ifb4eth1 up # important 
tc filter add dev eth1 parent ffff:  matchall action mirred egress redirect dev ifb4eth1

 
 
Run iperf3 -c 192.168.99.1 -p 3030 -t 10 -P 10 on the test device to measure the uplink data of the Test router.


There will still be latency, but this is much better than before, indicating that buffbloat has improved.

 
 
Run iperf3 -c 192.168.99.1 -p 3030 -t 10 -P 10 -R on the test device to measure the downlink data of the Test router.


Latency is almost the same as before the qos policy was set and has not improved

 
 
For the above test, I refer to the official buffbloat example.CakeRecipes - Bufferbloat.net
I tried to configure layer_cake.qos and piece_of_cake.qos scripts directly using sqm-script and got the same results.

SQM’s cake strategy improves upstream buffbloat from testing results, but if a device on your network is downloading a large file, your other devices may still encounter buffbloat.

Of course, my knowledge of qos configuration is very limited, and this is a very hasty conclusion. If you have any other test suggestions, please let me know

3 Likes

cake per host isolation will avoid this… also please report cpu usage with top/htop while testing… thank you.

tc-cake(8) - Linux manual page.

1 Like

I really want cake on my Vellica. :cry:

1 Like

I’m kind of late to this thread, but I’m pleased to see a 40 kb test actually work to reduce latencies even this much!!! a key thing to note is that once you get into mb, latencies under load stay almost entirely flat. If it helps any on future testing, I’ve been trying to show people how to use flent.org as a test tool of fifos, fq_codel, and cake in multiple threads around the internet.

We’re all in this bloat together, and I hope we can all work together to keep making the internet better. The mikrotik thread is presently the most comprehensive and goes deep into the theory:

https://forum.mikrotik.com/viewtopic.php?t=179307

My hope is to blog more about everyone’s experiences, anecdotes, and test resuls on my blog.