Maybe I can help out here.
I believe you are talking about two different issues here. Dave notes that
"traffic shaping" performance seems to top out at ~800 Mbps and you interpret
that to mean CoDel being the rate limiting step here. The number seems a bit
low though, I have seen unidirectional traffic shaping up to ~940 Mbps on a 1.6
GHz dual core arm a9 Marvell Armada 380/385 SoC (under bidirectional stress
however it topped out at ~500/500 Mbps with cake as shaper). Raspberry pi 4Bs
are reported (on the openwrt forum) to allow bidirectional traffic shaping at >
900Mbps.
I am confident that this device will happily run CoDel and even
fq_codel close to line-rate, as codel/fq_codel have a relative modest
processing cost. Traffic shaping however, at least as implemented in Linux'
TBF, HTB, HFSC, and cake qdiscs is a different beast and quite CPU intensive.
That might actually top out at ~800 Mbps on that device. (In my understanding
the issue with shaping is more of a latency than throughput issue, if the
traffic shaper is not to push large bursts of data into the next layer, it
basically wants to yield CPU only until shortly before the lower level drivers
run dry to then only admit a small batch of packets, and at increasingly faster
links the serialization time of an individual packet becomes shorter and
shorter increasing the CPU "neediness" of traffic shapers).
I also guess that the Ubiquity numbers assume the use of some offload
engines that might or might not be supported by main line linux, but that is
not backed by factual knowledge.
Hope that helps
Sebastian
> On Jan 22, 2021, at 20:42, Stuart Cheshire via Bloat
> <[email protected]> wrote:
>
> On 20 Jan 2021, at 07:55, Dave Taht <[email protected]> wrote:
>
>> This review, highly recommending this router on the high end
>>
>> https://www.increasebroadbandspeed.co.uk/best-router-2020
>>
>> also states that the sqm implementation has been dumbed down significantly
>> and can only shape 800Mbit inbound. Long ago we did a backport of cake to
>> the other ubnt routers mentioned in the review, has anyone tackled this one?
>
> According to the UniFi Dream Machine Pro data sheet, it has a 1.7 GHz
> quad-core ARM Cortex-A57 processor and achieves the following throughput
> numbers (downlink direction):
>
> 8.0 Gb/s with Deep Packet Inspection
> 3.5 Gb/s with DPI + Intrusion Detection
> 0.8 Gb/s with IPsec VPN
>
> <https://dl.ubnt.com/ds/udm-pro>
>
> Is implementing CoDel queueing really 10x more burden than running
> “Ubiquiti’s proprietary Deep Packet Inspection (DPI) engine”? Is CoDel 4x
> more burden than Ubiquiti’s IDS (Intrusion Detection System) and IPS
> (Intrusion Prevention System)?
>
> Is CoDel really the same per-packet cost as doing full IPsec VPN decryption
> on every packet? I realize the IPsec VPN decryption probably has some assist
> from crypto-specific ARM instructions or hardware, but even so, crypto
> operations are generally considered relatively expensive. If this device can
> do 800 Mb/s throughput doing IPsec VPN decryption for every packet, it feels
> like it ought to be able to do a lot better than that just doing CoDel
> queueing calculations for every packet.
>
> Is this just a software polish issue, that could be remedied by doing some
> performance optimization on the CoDel code?
>
> It’s also possible that the information in the review might simply be wrong
> -- it’s hard to measure throughput numbers in excess of 1 Gb/s unless you
> have both a client and a server connected faster than that in order to run
> the test. In other words, gigabit Ethernet is out, so both client and server
> would have to be connected via the 10 Gb/s SFP+ ports (of which the UDM-PRO
> has just two -- one in the upstream direction, and one in the downstream
> direction). Speaking for myself personally, I don’t have any devices with 10
> Gb/s capability, and my Internet connection isn’t above 1 Gb/s either, so as
> long as it can get reasonably close to 1 Gb/s that’s more than I need (or
> could use) right now.
>
> Stuart Cheshire
>
> _______________________________________________
> Bloat mailing list
> [email protected]
> https://lists.bufferbloat.net/listinfo/bloat
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
