From: Stuart Cheshire <cheshire@apple.com>
To: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] UniFi Dream Machine Pro
Date: Fri, 22 Jan 2021 11:42:54 -0800 [thread overview]
Message-ID: <932357EB-614C-4F74-925C-A1D6FB5F3AD2@apple.com> (raw)
In-Reply-To: <CAA93jw655Oji+wqbt-W32NHRvYaNfQUmR2rQEutEOxBRqGEoPQ@mail.gmail.com>
On 20 Jan 2021, at 07:55, Dave Taht <dave.taht@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
next prev parent reply other threads:[~2021-01-22 19:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 15:55 Dave Taht
2021-01-22 19:42 ` Stuart Cheshire [this message]
2021-01-22 20:42 ` Sebastian Moeller
2021-01-22 21:09 ` Toke Høiland-Jørgensen
2021-01-22 21:43 ` Jonathan Morton
2021-01-23 23:19 ` Dave Taht
2021-01-24 6:50 ` Mikael Abrahamsson
2021-01-23 23:30 ` Dave Taht
2021-01-24 0:31 ` Nils Andreas Svee
2021-01-24 1:08 ` Nils Andreas Svee
2021-01-26 16:02 ` Dave Taht
2021-01-27 22:58 ` Nils Andreas Svee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=932357EB-614C-4F74-925C-A1D6FB5F3AD2@apple.com \
--to=cheshire@apple.com \
--cc=bloat@lists.bufferbloat.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox