[Bloat] UniFi Dream Machine Pro

[Sebastian Moeller]

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 <bloat at lists.bufferbloat.net> wrote:
> 
> On 20 Jan 2021, at 07:55, Dave Taht <dave.taht at gmail.com> 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
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat