<div dir="ltr"><div>G'day,</div><div><br></div><div>Just a small update on the Unifi security gateway stuff. They have a new range of devices which are a lot more powerful.</div><div>( <a href="https://store.ui.com/us/en/collections/cloud-gateway-ultra/products/ucg-ultra">https://store.ui.com/us/en/collections/cloud-gateway-ultra/products/ucg-ultra</a> )<br></div><div><br></div><div>The good news is that the limits set in the GUI now match exactly the "rate" set in the qcdisc.<br></div><div><br></div><div><span style="font-family:monospace">root@UCG-Ultra:~# <b>tc -p -s -d qdisc show dev eth4</b><br>qdisc htb 1: root refcnt 5 r2q 10 default 0x2 direct_packets_stat 0 ver 3.17 direct_qlen 1000<br> Sent 13112672757 bytes 41407610 pkt (dropped 2863, overlimits 12123381 requeues 0) <br> backlog 0b 0p requeues 0<br>qdisc fq_codel 2: parent 1:2 limit 2000p flows 1024 quantum 300 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64 <br> Sent 13112672757 bytes 41407610 pkt (dropped 2863, overlimits 0 requeues 0) <br> backlog 0b 0p requeues 0<br> maxpacket 27888 drop_overlimit 0 new_flow_count 9175282 ecn_mark 0<br> new_flows_len 1 old_flows_len 3<br>qdisc ingress ffff: parent ffff:fff1 ---------------- <br> Sent 104038056896 bytes 143646981 pkt (dropped 0, overlimits 0 requeues 0) <br> backlog 0b 0p requeues 0<br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">root@UCG-Ultra:/etc/systemd# <b>tc -d class show dev eth4</b><br>class htb 1:1 root <span style="background-color:rgb(255,242,204)">rate 35Mbit </span>ceil 35Mbit linklayer ethernet burst 1491b/1 mpu 0b cburst 1491b/1 mpu 0b level 7 <br>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 <br>class fq_codel 2:1bf parent 2: <br>class fq_codel 2:274 parent 2: <br>class fq_codel 2:296 parent 2: <br>class fq_codel 2:2ca parent 2: <br>class fq_codel 2:34a parent 2: <br>class fq_codel 2:364 parent 2: <br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">root@UCG-Ultra:~# <b>tc -p -s -d qdisc show dev ifbeth4</b><br>qdisc htb 1: root refcnt 2 r2q 10 default 0x2 direct_packets_stat 0 ver 3.17 direct_qlen 1000<br> Sent 108770017013 bytes 143572868 pkt (dropped 24028, overlimits 43487579 requeues 0) <br> backlog 0b 0p requeues 0<br>qdisc fq_codel 2: parent 1:2 limit 2000p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 4Mb ecn drop_batch 64 <br> Sent 108770017013 bytes 143572868 pkt (dropped 24028, overlimits 0 requeues 0) <br> backlog 0b 0p requeues 0<br> maxpacket 69876 drop_overlimit 10448 new_flow_count 14414347 ecn_mark 0 drop_overmemory 10448<br> new_flows_len 1 old_flows_len 2<br></span></div><div><span style="font-family:monospace"><br>root@UCG-Ultra:/etc/systemd# <b>tc -d class show dev ifbeth4</b><br>class htb 1:1 root <span style="background-color:rgb(255,242,204)">rate 800Mbit</span> ceil 800Mbit linklayer ethernet burst 1400b/1 mpu 0b cburst 1400b/1 mpu 0b level 7 <br>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 <br>class fq_codel 2:111 parent 2: <br>class fq_codel 2:3cc parent 2:</span></div><div><br></div><div>So 35Mb/s and 800Mb/s match what is configured in the GUI.<br></div><div><br></div><div><img src="cid:ii_lvlhqdqp0" alt="image.png" width="578" height="378"></div><div><br></div><div>The bad news is still no cake.</div><div><br></div><div>The bottleneck in my house is now the air interfaces. I'll run some flent tests soon.<br></div><div><br></div><div>Thanks,</div><div>Dave Seddon</div><div><br></div><div><br></div><div>Other device details....<br></div><div><br></div><div>root@UCG-Ultra:~# uname -a<br>Linux UCG-Ultra 5.4.213-ui-ipq5322 #5.4.213 SMP PREEMPT Fri Jan 26 01:53:55 CST 2024 aarch64 GNU/Linux</div><div><br></div><div>root@UCG-Ultra:~# cat /proc/cpuinfo <br>processor : 0<br>BogoMIPS : 48.00<br>Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid<br>CPU implementer : 0x51<br>CPU architecture: 8<br>CPU variant : 0xa<br>CPU part : 0x801<br>CPU revision : 4<br><br>processor : 1<br>BogoMIPS : 48.00<br>Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid<br>CPU implementer : 0x51<br>CPU architecture: 8<br>CPU variant : 0xa<br>CPU part : 0x801<br>CPU revision : 4<br><br>processor : 2<br>BogoMIPS : 48.00<br>Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid<br>CPU implementer : 0x51<br>CPU architecture: 8<br>CPU variant : 0xa<br>CPU part : 0x801<br>CPU revision : 4<br><br>processor : 3<br>BogoMIPS : 48.00<br>Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid<br>CPU implementer : 0x51<br>CPU architecture: 8<br>CPU variant : 0xa<br>CPU part : 0x801<br>CPU revision : 4<br></div><div><br></div><div><br></div><div>root@UCG-Ultra:~# cat /proc/interrupts <br> CPU0 CPU1 CPU2 CPU3 <br> 4: 49385470 71684295 74561605 77496134 GIC-0 20 Level arch_timer<br> 6: 0 0 0 0 GIC-0 39 Level arch_mem_timer<br> 8: 0 0 0 0 GIC-0 195 Level edma_txcmpl_4<br> 9: 0 0 0 0 GIC-0 196 Level edma_txcmpl_5<br> 10: 0 0 0 0 GIC-0 197 Level edma_txcmpl_6<br> 11: 0 0 0 0 GIC-0 198 Level edma_txcmpl_7<br> 12: 1301701 0 0 0 GIC-0 199 Level edma_txcmpl_8<br> 13: 16537922 0 0 0 GIC-0 200 Level edma_txcmpl_9<br> 14: 16902391 0 0 0 GIC-0 201 Level edma_txcmpl_10<br> 15: 19093638 0 0 0 GIC-0 202 Level edma_txcmpl_11<br> 16: 218358 0 0 0 GIC-0 203 Level edma_txcmpl_12<br> 17: 14172534 0 0 0 GIC-0 204 Level edma_txcmpl_13<br> 18: 12228644 0 0 0 GIC-0 205 Level edma_txcmpl_14<br> 19: 14848643 0 0 0 GIC-0 206 Level edma_txcmpl_15<br> 20: 141424886 0 0 0 GIC-0 171 Level edma_rxdesc_12<br> 21: 10923594 0 0 0 GIC-0 172 Level edma_rxdesc_13<br> 22: 10953671 0 0 0 GIC-0 173 Level edma_rxdesc_14<br> 23: 13031550 0 0 0 GIC-0 174 Level edma_rxdesc_15<br> 24: 0 0 0 0 GIC-0 223 Level edma_misc<br> 33: 5199506 0 0 0 GIC-0 321 Level bam_dma<br> 34: 929 0 0 0 GIC-0 322 Level msm_serial0<br> 35: 10465714 0 0 0 GIC-0 345 Level mmc0<br> 36: 3 0 0 0 GIC-0 348 Level 7804000.sdhci<br> 37: 40125 0 0 0 GIC-0 324 Level 78b5000.spi<br> 38: 5187812 0 0 0 GIC-0 326 Level 78b7000.spi<br> 39: 9865790 0 0 0 GIC-0 325 Level i2c_qup<br> 45: 0 0 0 0 GIC-0 450 Edge smp2p<br> 46: 0 0 0 0 GIC-0 453 Edge q6v5 wdog<br> 47: 0 0 0 0 GIC-0 352 Edge tsens_interrupt<br> 48: 0 0 0 0 GIC-0 23 Level arm-pmu<br> 49: 0 0 0 0 GIC-0 299 Edge tzerror<br> 50: 360 0 0 0 GIC-0 96 Level xhci-hcd:usb1<br> 51: 0 0 0 0 smp2p 0 Edge q6v5 fatal<br> 52: 0 0 0 0 smp2p 1 Edge q6v5 ready<br> 53: 0 0 0 0 smp2p 2 Edge q6v5 handover<br> 54: 0 0 0 0 smp2p 3 Edge q6v5 stop<br> 55: 0 0 0 0 smp2p 8 Edge q6v5_wcss_userpd1_fatal<br> 56: 0 0 0 0 smp2p 9 Edge q6v5_wcss_userpd1_ready<br> 57: 0 0 0 0 smp2p 12 Edge q6v5_wcss_userpd1_spawn_ack<br> 58: 0 0 0 0 smp2p 11 Edge q6v5_wcss_userpd1_stop_ack<br> 59: 0 0 0 0 msmgpio 52 Edge Reset Button<br>IPI0: 11014796 16872295 17455146 17378253 Rescheduling interrupts<br>IPI1: 54693 31818397 30245960 124867604 Function call interrupts<br>IPI2: 0 0 0 0 CPU stop interrupts<br>IPI3: 0 0 0 0 CPU stop (for crash dump) interrupts<br>IPI4: 0 0 0 0 Timer broadcast interrupts<br>IPI5: 914 0 0 0 IRQ work interrupts<br>IPI6: 0 0 0 0 CPU wake-up interrupts<br>Err: 0<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 9, 2024 at 3:28 PM Nils Andreas Svee <<a href="mailto:me@lochnair.net">me@lochnair.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>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.</div><div><br></div><div>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: <a href="https://forum.openwrt.org/t/sqm-reporting/59960/96" target="_blank">https://forum.openwrt.org/t/sqm-reporting/59960/96</a></div><br id="m_7012884691258987246lineBreakAtBeginningOfMessage"><div>
<div>Best Regards,<br>Nils Andreas Svee</div>
</div>
<div><br><blockquote type="cite"><div>On Jan 9, 2024, at 18:17, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:</div><br><div><div>Principal limitation for libreqos on a small box is has to have<br>multiple hardware queues and support eBPF.<br><br>Seriously folks, running libreqos at home is *serious overkill*,<br>although I have to admit the traffic graphs are mesmerizing!!! One of<br>our ISPs has been setting them to music:<br><a href="https://www.youtube.com/@trendaltoews7143" target="_blank">https://www.youtube.com/@trendaltoews7143</a><br><br>Herbert has been working on adding all sorts of other analytics to it also.<br><br>On Tue, Jan 9, 2024 at 12:07 PM dave seddon <<a href="mailto:dave.seddon.ca@gmail.com" target="_blank">dave.seddon.ca@gmail.com</a>> wrote:<br><blockquote type="cite"><br>Nils - I guess you could run LibreQoS on N100?<br><br>On Tue, Jan 9, 2024 at 8:57 AM Nils Andreas Svee via Cake <<a href="mailto:cake@lists.bufferbloat.net" target="_blank">cake@lists.bufferbloat.net</a>> wrote:<br><blockquote type="cite"><br>On Jan 9, 2024, at 17:05, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.com</a>> wrote:<br><br>On Tue, Jan 9, 2024 at 10:40 AM Nils Andreas Svee via Cake<br><<a href="mailto:cake@lists.bufferbloat.net" target="_blank">cake@lists.bufferbloat.net</a>> wrote:<br><br>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.<br><br><br>This irks me enormously. It is the direct outcome of the cambium<br>elevate lawsuit, where both companies lost, the ISPs lost, open source<br>practices long established about publishing sources, lost, and the<br>lawyers went on to other nasty things leaving this trail of awful<br>precedents in their wake.<br><br><a href="https://www.mtin.net/blog/ubnt-vs-cambium/" target="_blank">https://www.mtin.net/blog/ubnt-vs-cambium/</a><br><br>Wow, hadn’t read about that. They even sued an ISP just for using Cambium’s software on their hardware?<br>That is crazy, just evil corporate lawyers doing their thing I guess.<br><br>I do not know what to do about it. It also irks me that as a<br>contributor to "smart queues" they are not maintaining it well.<br><br>It leaves something to be desired yes, and I would’ve hoped to see CAKE included too of course,<br>but even WireGuard is only available in the latest release candidates with the redesigned web UI, so I’m not holding my breath.<br><br>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.<br><br>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 ;)<br><br>One of those Chinese boxes with a N100 in it and OpenWrt on top works wonders :)<br><br>Best Regards,<br>Nils Andreas Svee<br>_______________________________________________<br>Cake mailing list<br><a href="mailto:Cake@lists.bufferbloat.net" target="_blank">Cake@lists.bufferbloat.net</a><br><a href="https://lists.bufferbloat.net/listinfo/cake" target="_blank">https://lists.bufferbloat.net/listinfo/cake</a><br></blockquote><br><br><br>--<br>Regards,<br>Dave Seddon<br>+1 415 857 5102<br></blockquote><br><br><br>-- <br>40 years of net history, a couple songs:<br><a href="https://www.youtube.com/watch?v=D9RGX6QFm5E" target="_blank">https://www.youtube.com/watch?v=D9RGX6QFm5E</a><br>Dave Täht CSO, LibreQos<br></div></div></blockquote></div><br></div></blockquote></div><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Regards,<br></div>Dave Seddon<br>+1 415 857 5102<br></div></div></div></div></div></div>