Bufferbloat & SQM & Omnia

Software SW tweaks
21

Of course, from my talk on the bufferbloat WiFi was completely excluded. I have been misunderstood. The WiFi limit is general and concerns Gigabit management, but it is a problem up to the WiFi 5 protocol. The bufferbloat problem on Omnia is the normal one, due to the ISP and which is solvable for limited bandwidth speeds or with a processor that handles packets better.

1 Like
22

Yes, sorry. Then again, always good to document what can be expected under typical conditions, even if these conditions do not apply in the specific case :wink:

23

I’m on GPON. As mentioned I’m doing the bufferbloat tests on wired, not WiFi. I agree that with the current state of TurrisOS as you approach gigabit speeds things don’t work well in this area.

24

With some tinkering I did get around 650Mbps bidirectionally with a score of A, including a good mark for low latency gaming, on https://www.waveform.com/tools/bufferbloat The Omnia currently seems to max out at around those speeds with SQM active. This is my test result: https://www.waveform.com/tools/bufferbloat?test-id=b6641187-0533-4c3f-8ada-5fa102093f47

Here’s what I did:

I used Google Chrome as the test browser on macOS.

I configured SQM as per the SQM “how-to” https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm but I added the “nat dual-dsthost” and “nat dual-srchost” as recommended here: How to use the cake queue management system on the Turris Omnia

I edited /etc/hotplug.d/net/20-smp-tune similar to what @moeller0 recommended to ensure both CPUs are used, but like this (from post about another OpenWRT device with similar issue at https://forum.openwrt.org/t/18-06-4-speed-fix-for-bt-homehub-5a/23643

for q in ${dev}/queues/rx-*; do
        set_hex_val "$q/rps_cpus" "$PROC_MASK"
done

for q in ${dev}/queues/tx-*; do
        set_hex_val "$q/xps_cpus" "$PROC_MASK"
done

I understand that the need for the above modification to /etc/hotplug.d/net/20-smp-tune should be gone with Turris 6.0 when option packet_steering '1' will be supported in the global options in /etc/config/network. In the meantime would it make sense for the Turris to ship a /etc/hotplug.d/net/20-smp-tune with the above change?

The FAQ for the test says that to meet the requirements for “low latency gaming” the 95th percentile latency for both upload and download needs to be < 40ms. I experimented with the download and upload speeds to adjust them to where the test could consistently return that 95th percentile latency, for me that was around 680 Mbps.

2 Likes
25

Ah, the waveform test is sequentially, so they first load one direction and after that test is done the reverse direction, if you get 650 Mbps in both direction, that means uni-directional shaping tops out at ~ 650 Mbps (in my older tests I got unidirectional results up to ~940 Mbps, but that was tested inside my LAN with a much older TOS version)… If you use flent’s RRUL or RRUL_CS8 test you can test the real bidirectional shaping capabilities, which I guess will be somewhere around 325/325 (for SQM the shaper capacity seems to be limited to roughly the same limit, independent on how you split between ingress and egress direction, at least on the router SoCs I tried it on).

Yes, that seems a bit less hackish than y quick and dirty proposal above, but since the Omnia will not grow additional CPU cores anytime soon, this should effectively boil down to the same (if I had remembered maurer’s post I would have just linked it :wink:

+1; I think that might make sense, unless TOS 6.0 is near.

That is a sane approach, to tune based on actual data; I add though that the 95%ile < 40 ms is probably a heuristic that will work better for some games than for others. (But I stopped FPS/reaction time gated gaming in the late 90s, so no idea which games are more sensitve).

26

I used the modification you reported from the post https://forum.openwrt.org/t/18-06-4-speed-fix-for-bt-homehub-5a/23643/30 in the thread https://forum.openwrt.org/t/18-06-4-speed-fix-for-bt-homehub-5a/23643. I then realized that I had also participated in that thread, but then it was for another reason. By making the aforementioned changes to 20-smp-tune I was able to have a 15% improvement over the shaper in download to get A+ and pass all the tests under load of https://www.waveform.com/tools/bufferbloat. Too bad that the change is not made on the current stable version of OpenWrt, but we are already looking at the new rc version, which should be upon us, since so much stuff was already in testing under master for a year.

2 Likes