Introduction

The good folks of NBN Co recently gave everyone on higher plans a free bandwidth upgrade, so my connection was bumped to 500/50 Mb/s as a result. As a long term user of MikroTik RB750GL (retired) and hEX routers, I thought a simple reconfiguration of max bandwidth in fq-codel queues would suffice. Unfortunately, it was not that easy...

Fasttrack required

With the bandwith update, the first problem was that fasttrack rules were now a must on this router. The MMIPS 880 MHz CPU on the original hEX (RB750Gr3) just wasn't fast enough to process all the firewall rules without the help of fasttrack.

But, configuring fasttrack meant that simple queue that I used before would no longer work. Not a problem - I configured queue trees with bridge and WAN interfaces as parents.

Turns out, running fq-codel at the new bandwith was also not feasible on the original hEX. The router would max out at about 250+ Mb/s. Similar with cake.

A Flint2 and OpenWRT detour

Just to see whether my theory was sound, I briefly repurposed my GL.iNET Flint2 (GL-MT6000) as the router for this NBN connection. Indeed, faster CPU and the goodies contained in OpenWRT delivered the desired result. Increase in latency under load (download, to be exact) was limited to single digit ms.

Just as Waveform's bufferbloat FAQ explains, these findings only apply to ethernet. Increase in latency when using WiFi is higher, most likely becuase wireless interfaces use their own (unmanaged?) buffers, thus contributing to the problem.

hEX refresh

After the successful test with Flint2, I decided to purchase hEX refresh (E50UG) device. It was only AU$100 from WISP. It comes with an ARM 64-bit CPU, which is running in 32-bit mode. It has two CPU cores clocked at 950 MHz, but they are a lot more efficient than MMIPS ones in the original hEX.

After configuring queue tree like this:

/queue tree
add max-limit=498M name=download packet-mark=no-mark parent=bridge queue=fq-codel
add max-limit=48M name=upload packet-mark=no-mark parent=ether1 queue=fq-codel


The setup was fighting bufferbloat (over ethernet) pretty successfully. The increase in latency under load (download) was again in single digit ms.

I did try cake instead of fq-codel as well, but this was pushing one of the CPU cores to 100% utilisation, with no measurable difference in latencies. So, I settled on fq-codel, which appears to be a touch lighter on processing requirements. It does push one of the CPU cores to about 85% to 95% utilisation at times, so this bandwidth is likely the maximum this router can handle.

As before, using WiFi will increase the latency under load significantly more and it is not immediately obvious what can be done about that.

Conclusion

For a 500/50 Mb/s NBN connections, MikroTik hEX refresh apprears to be sufficiently powerful to run fq-codel smart queue management for bufferbloat reduction. I am pretty sure that going above that would bring the router CPU to its knees, so using something else is likely a better idea.

Copyright © 2025 Bojan Smojver.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the licence is here.