[Cake] Ubiquity (Unifi ) Smart Queues
dave seddon
dave.seddon.ca at gmail.com
Mon Apr 29 17:55:07 EDT 2024
G'day,
Just a small update on the Unifi security gateway stuff. They have a new
range of devices which are a lot more powerful.
(
https://store.ui.com/us/en/collections/cloud-gateway-ultra/products/ucg-ultra
)
The good news is that the limits set in the GUI now match exactly the
"rate" set in the qcdisc.
root at UCG-Ultra:~# *tc -p -s -d qdisc show dev eth4*
qdisc htb 1: root refcnt 5 r2q 10 default 0x2 direct_packets_stat 0 ver
3.17 direct_qlen 1000
Sent 13112672757 bytes 41407610 pkt (dropped 2863, overlimits 12123381
requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 2: parent 1:2 limit 2000p flows 1024 quantum 300 target 5ms
interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 13112672757 bytes 41407610 pkt (dropped 2863, overlimits 0 requeues
0)
backlog 0b 0p requeues 0
maxpacket 27888 drop_overlimit 0 new_flow_count 9175282 ecn_mark 0
new_flows_len 1 old_flows_len 3
qdisc ingress ffff: parent ffff:fff1 ----------------
Sent 104038056896 bytes 143646981 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
root at UCG-Ultra:/etc/systemd# *tc -d class show dev eth4*
class htb 1:1 root rate 35Mbit ceil 35Mbit linklayer ethernet burst 1491b/1
mpu 0b cburst 1491b/1 mpu 0b level 7
class htb 1:2 parent 1:1 leaf 2: prio 7 quantum 1514 rate 64bit ceil 35Mbit
linklayer ethernet burst 1500b/1 mpu 0b cburst 1491b/1 mpu 0b level 0
class fq_codel 2:1bf parent 2:
class fq_codel 2:274 parent 2:
class fq_codel 2:296 parent 2:
class fq_codel 2:2ca parent 2:
class fq_codel 2:34a parent 2:
class fq_codel 2:364 parent 2:
root at UCG-Ultra:~# *tc -p -s -d qdisc show dev ifbeth4*
qdisc htb 1: root refcnt 2 r2q 10 default 0x2 direct_packets_stat 0 ver
3.17 direct_qlen 1000
Sent 108770017013 bytes 143572868 pkt (dropped 24028, overlimits 43487579
requeues 0)
backlog 0b 0p requeues 0
qdisc fq_codel 2: parent 1:2 limit 2000p flows 1024 quantum 1514 target 5ms
interval 100ms memory_limit 4Mb ecn drop_batch 64
Sent 108770017013 bytes 143572868 pkt (dropped 24028, overlimits 0
requeues 0)
backlog 0b 0p requeues 0
maxpacket 69876 drop_overlimit 10448 new_flow_count 14414347 ecn_mark 0
drop_overmemory 10448
new_flows_len 1 old_flows_len 2
root at UCG-Ultra:/etc/systemd# *tc -d class show dev ifbeth4*
class htb 1:1 root rate 800Mbit ceil 800Mbit linklayer ethernet burst
1400b/1 mpu 0b cburst 1400b/1 mpu 0b level 7
class htb 1:2 parent 1:1 leaf 2: prio 7 quantum 1514 rate 64bit ceil
800Mbit linklayer ethernet burst 1500b/1 mpu 0b cburst 1400b/1 mpu 0b level
0
class fq_codel 2:111 parent 2:
class fq_codel 2:3cc parent 2:
So 35Mb/s and 800Mb/s match what is configured in the GUI.
[image: image.png]
The bad news is still no cake.
The bottleneck in my house is now the air interfaces. I'll run some flent
tests soon.
Thanks,
Dave Seddon
Other device details....
root at UCG-Ultra:~# uname -a
Linux UCG-Ultra 5.4.213-ui-ipq5322 #5.4.213 SMP PREEMPT Fri Jan 26 01:53:55
CST 2024 aarch64 GNU/Linux
root at UCG-Ultra:~# cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4
processor : 1
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4
processor : 2
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid
CPU implementer : 0x51
CPU architecture: 8
CPU variant : 0xa
CPU part : 0x801
CPU revision : 4
root at UCG-Ultra:~# cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3
4: 49385470 71684295 74561605 77496134 GIC-0 20 Level
arch_timer
6: 0 0 0 0 GIC-0 39 Level
arch_mem_timer
8: 0 0 0 0 GIC-0 195 Level
edma_txcmpl_4
9: 0 0 0 0 GIC-0 196 Level
edma_txcmpl_5
10: 0 0 0 0 GIC-0 197 Level
edma_txcmpl_6
11: 0 0 0 0 GIC-0 198 Level
edma_txcmpl_7
12: 1301701 0 0 0 GIC-0 199 Level
edma_txcmpl_8
13: 16537922 0 0 0 GIC-0 200 Level
edma_txcmpl_9
14: 16902391 0 0 0 GIC-0 201 Level
edma_txcmpl_10
15: 19093638 0 0 0 GIC-0 202 Level
edma_txcmpl_11
16: 218358 0 0 0 GIC-0 203 Level
edma_txcmpl_12
17: 14172534 0 0 0 GIC-0 204 Level
edma_txcmpl_13
18: 12228644 0 0 0 GIC-0 205 Level
edma_txcmpl_14
19: 14848643 0 0 0 GIC-0 206 Level
edma_txcmpl_15
20: 141424886 0 0 0 GIC-0 171 Level
edma_rxdesc_12
21: 10923594 0 0 0 GIC-0 172 Level
edma_rxdesc_13
22: 10953671 0 0 0 GIC-0 173 Level
edma_rxdesc_14
23: 13031550 0 0 0 GIC-0 174 Level
edma_rxdesc_15
24: 0 0 0 0 GIC-0 223 Level
edma_misc
33: 5199506 0 0 0 GIC-0 321 Level
bam_dma
34: 929 0 0 0 GIC-0 322 Level
msm_serial0
35: 10465714 0 0 0 GIC-0 345 Level
mmc0
36: 3 0 0 0 GIC-0 348 Level
7804000.sdhci
37: 40125 0 0 0 GIC-0 324 Level
78b5000.spi
38: 5187812 0 0 0 GIC-0 326 Level
78b7000.spi
39: 9865790 0 0 0 GIC-0 325 Level
i2c_qup
45: 0 0 0 0 GIC-0 450 Edge
smp2p
46: 0 0 0 0 GIC-0 453 Edge
q6v5 wdog
47: 0 0 0 0 GIC-0 352 Edge
tsens_interrupt
48: 0 0 0 0 GIC-0 23 Level
arm-pmu
49: 0 0 0 0 GIC-0 299 Edge
tzerror
50: 360 0 0 0 GIC-0 96 Level
xhci-hcd:usb1
51: 0 0 0 0 smp2p 0 Edge
q6v5 fatal
52: 0 0 0 0 smp2p 1 Edge
q6v5 ready
53: 0 0 0 0 smp2p 2 Edge
q6v5 handover
54: 0 0 0 0 smp2p 3 Edge
q6v5 stop
55: 0 0 0 0 smp2p 8 Edge
q6v5_wcss_userpd1_fatal
56: 0 0 0 0 smp2p 9 Edge
q6v5_wcss_userpd1_ready
57: 0 0 0 0 smp2p 12 Edge
q6v5_wcss_userpd1_spawn_ack
58: 0 0 0 0 smp2p 11 Edge
q6v5_wcss_userpd1_stop_ack
59: 0 0 0 0 msmgpio 52 Edge
Reset Button
IPI0: 11014796 16872295 17455146 17378253 Rescheduling
interrupts
IPI1: 54693 31818397 30245960 124867604 Function call
interrupts
IPI2: 0 0 0 0 CPU stop interrupts
IPI3: 0 0 0 0 CPU stop (for crash
dump) interrupts
IPI4: 0 0 0 0 Timer broadcast
interrupts
IPI5: 914 0 0 0 IRQ work interrupts
IPI6: 0 0 0 0 CPU wake-up
interrupts
Err: 0
On Tue, Jan 9, 2024 at 3:28 PM Nils Andreas Svee <me at lochnair.net> wrote:
> Well my NIC has 4 queues as far as I can tell, so it could likely work,
> but as you say it’s like killing a mosquito with a gatling gun.
>
> Those graphs are sweet though, and it’s been in my backlog for awhile to
> do something with Grafana to get something similar, like this one from a
> few years ago you’ve seen too:
> https://forum.openwrt.org/t/sqm-reporting/59960/96
>
> Best Regards,
> Nils Andreas Svee
>
> On Jan 9, 2024, at 18:17, Dave Taht <dave.taht at gmail.com> wrote:
>
> Principal limitation for libreqos on a small box is has to have
> multiple hardware queues and support eBPF.
>
> Seriously folks, running libreqos at home is *serious overkill*,
> although I have to admit the traffic graphs are mesmerizing!!! One of
> our ISPs has been setting them to music:
> https://www.youtube.com/@trendaltoews7143
>
> Herbert has been working on adding all sorts of other analytics to it also.
>
> On Tue, Jan 9, 2024 at 12:07 PM dave seddon <dave.seddon.ca at gmail.com>
> wrote:
>
>
> Nils - I guess you could run LibreQoS on N100?
>
> On Tue, Jan 9, 2024 at 8:57 AM Nils Andreas Svee via Cake <
> cake at lists.bufferbloat.net> wrote:
>
>
> On Jan 9, 2024, at 17:05, Dave Taht <dave.taht at gmail.com> wrote:
>
> On Tue, Jan 9, 2024 at 10:40 AM Nils Andreas Svee via Cake
> <cake at lists.bufferbloat.net> wrote:
>
> Though frankly, I don’t plan on updating the sch_cake and tc binaries when
> new firmwares are released anymore, as they don’t publish the GPL archives
> on their webpage after the redesign, and they don’t respond to requests for
> them either by the looks of the forums. So if it breaks there’s not much I
> can do anymore.
>
>
> This irks me enormously. It is the direct outcome of the cambium
> elevate lawsuit, where both companies lost, the ISPs lost, open source
> practices long established about publishing sources, lost, and the
> lawyers went on to other nasty things leaving this trail of awful
> precedents in their wake.
>
> https://www.mtin.net/blog/ubnt-vs-cambium/
>
> Wow, hadn’t read about that. They even sued an ISP just for using
> Cambium’s software on their hardware?
> That is crazy, just evil corporate lawyers doing their thing I guess.
>
> I do not know what to do about it. It also irks me that as a
> contributor to "smart queues" they are not maintaining it well.
>
> It leaves something to be desired yes, and I would’ve hoped to see CAKE
> included too of course,
> but even WireGuard is only available in the latest release candidates with
> the redesigned web UI, so I’m not holding my breath.
>
> I still have an EdgeRouter 4 that serves the family farm and one of the
> 8-port switches under my desk, if only because I don’t wanna spend money on
> replacing them, and they do serve their purpose.
>
> I’ve since moved though, and now live in an area that has FTTH, so I
> needed something beefier to handle CAKE on a 750/750 subscription, because
> obviously there’s still bloat even on that ;)
>
> One of those Chinese boxes with a N100 in it and OpenWrt on top works
> wonders :)
>
> Best Regards,
> Nils Andreas Svee
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>
>
>
>
> --
> Regards,
> Dave Seddon
> +1 415 857 5102
>
>
>
>
> --
> 40 years of net history, a couple songs:
> https://www.youtube.com/watch?v=D9RGX6QFm5E
> Dave Täht CSO, LibreQos
>
>
>
--
Regards,
Dave Seddon
+1 415 857 5102
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20240429/ba3ee452/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 32758 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20240429/ba3ee452/attachment-0001.png>
More information about the Cake
mailing list