On Thu, Jan 14, 2021 at 2:07 PM Robert Chacon <robert.chacon@jackrabbitwireless.com> wrote:
> Cool! What kind of performance are you seeing? The README mentions being
> limited by the BPF hash table size, but can you actually shape 2000
> customers on one machine? On what kind of hardware and at what rate(s)?On our production network our peak throughput is 1.5Gbps from 200 clients, and it works very well.We use a simple consumer-class AMD 2700X CPU in production because utilization of the shaper VM is ~15% at 1.5Gbps load.Customers get reliably capped within ±2Mbps of their allocated htb/fq_codel bandwidth, which is very helpful to control network congestion.Here are some graphs from RRUL performed on our test bench hypervisor: https://raw.githubusercontent.com/rchac/LibreQoS/main/docs/fq_codel_1000_subs_4G.pngIn that example, bandwidth for the "subscriber" client VM was set to 4Gbps. 1000 IPv4 IPs and 1000 IPv6 IPs were in the filter hash table of LibreQoS.
What I really love about this plot is that it is now very possible for your customers to
play live music together with reasonable latencies and jitter, under load.
Existing tools like "jacktrip" should "just work. For a cool talk about the jacktrip
revolution: https://www.npr.org/2020/11/21/937043051/musicians-turn-to-new-software-to-play-together-online
I'm using cake to keep things under control on my testbed network, using ardour
as the mixing tool, and achieving about 6ms of inherent latency.
I am hoping to sink a bit of time into galene.org and various web browsers this
year to finally get closer to what the lola project has been doing for a while on the video front.
The test bench server has an AMD 3900X running Ubuntu in Proxmox. 4Gbps utilizes 10% of the VM's 12 cores. Paravirtualized VirtIO network drivers are used and most offloading types are enabled.In our setup, VM networking multiqueue isn't enabled (it kept disrupting traffic flow), so 6Gbps is probably the most it can achieve like this. Our qdiscs in this VM may be limited to one core because of that.I suspect in a non-virtualized setup, or one with multiqueue, it can handle much more throughput.Either way for now it's surprising to me how well it works and I'm just grateful for it haha.Kudos to you and your peers for making fq_codel so efficient!- RobertOn Thu, Jan 14, 2021 at 12:46 PM Toke Høiland-Jørgensen <toke@toke.dk> wrote:Robert Chacon <robert.chacon@jackrabbitwireless.com> writes:
> Hello everyone,
>
> I am new here, my name is Robert. I operate a small ISP in the US. I wanted
> to post here to thank Dave Täht, as well as the dozens of contributors to
> the fq_codel and cake projects.
Thank you for reaching out! It's always fun to hear about real-world
deployments of this technology, and it's great to hear that it's working
well for you! :)
> I created a simple python application that uses htb+fq_codel to shape my
> customers' traffic, and have seen great performance improvements. I am
> maintaining it as an open source project for other ISPs to use at
> https://github.com/rchac/LibreQoS
Cool! What kind of performance are you seeing? The README mentions being
limited by the BPF hash table size, but can you actually shape 2000
customers on one machine? On what kind of hardware and at what rate(s)?
-Toke
--_______________________________________________
Robert Chacón
Owner
M (915) 730-1472
E robert.chacon@jackrabbitwireless.comJackRabbit Wireless LLC
P.O. Box 222111
El Paso, TX 79913jackrabbitwireless.com
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat
