[Bloat] Thanks to developers / htb+fq_codel ISP shaper

[Dave Taht]

On Thu, Jan 14, 2021 at 2:07 PM Robert Chacon <
robert.chacon at 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.png
> In 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!
>
> - Robert
>
> On Thu, Jan 14, 2021 at 12:46 PM Toke Høiland-Jørgensen <toke at toke.dk>
> wrote:
>
>> Robert Chacon <robert.chacon at 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
>>
>
>
> --
> [image: photograph]
>
>
> *Robert Chacón* Owner
> *M* (915) 730-1472
> *E* robert.chacon at jackrabbitwireless.com
> *JackRabbit Wireless LLC*
> P.O. Box 222111
> El Paso, TX 79913
> *jackrabbitwireless.com* <http://jackrabbitwireless.com>
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>


-- 
"For a successful technology, reality must take precedence over public
relations, for Mother Nature cannot be fooled" - Richard Feynman

dave at taht.net <Dave Täht> CTO, TekLibre, LLC Tel: 1-831-435-0729
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20210120/c820190c/attachment.html>