Re: [LibreQoS] Before/After Performance Comparison (Monitoring Mode)

[Herbert Wolverson <herberticus@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]

Glancing at that, I love how simple it is. :-) I'll see if I can try it out
soon (I'm diving back into book writing for the day)

On Tue, Nov 8, 2022 at 9:45 AM Robert Chacón via LibreQoS <
libreqos@lists.bufferbloat.net> wrote:

> Point taken!
>
> Before receiving this email I had started work on it. It's on a branch on
> GitHub now <https://github.com/LibreQoE/LibreQoS/tree/monitor-mode/v1.3>.
> It uses cpumap-pping and keeps HTB, but overrides all HTB class and leaf
> rates to be 10Gbps so that borrowing isn't taking place anywhere - so we
> can be as transparent as possible.
>
> I'll try again another shot at monitoring-mode with ePPing instead.
>
> On Tue, Nov 8, 2022 at 7:23 AM Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
>
>> Robert Chacón via LibreQoS <libreqos@lists.bufferbloat.net> writes:
>>
>> > I was hoping to add a monitoring mode which could be used before
>> "turning
>> > on" LibreQoS, ideally before v1.3 release. This way operators can really
>> > see what impact it's having on end-user and network latency.
>> >
>> > The simplest solution I can think of is to implement Monitoring Mode
>> using
>> > cpumap-pping as we already do - with plain HTB and leaf classes with no
>> > CAKE qdisc applied, and with HTB and leaf class rates set to impossibly
>> > high amounts (no plan enforcement). This would allow for before/after
>> > comparisons of Nodes (Access Points). My only concern with this
>> approach is
>> > that HTB, even with rates set impossibly high, may not be truly
>> > transparent. It would be pretty easy to implement though.
>> >
>> > Alternatively we could use ePPing
>> > <https://github.com/xdp-project/bpf-examples/tree/master/pping> but I
>> worry
>> > about throughput and the possibility of latency tracking being slightly
>> > different from cpumap-pping, which could limit the utility of a
>> comparison.
>> > We'd have to match IPs in a way that's a bit more involved here.
>> >
>> > Thoughts?
>>
>> Well, this kind of thing is exactly why I think concatenating the two
>> programs (cpumap and pping) into a single BPF program was a mistake:
>> those are two distinct pieces of functionality, and you want to be able
>> to run them separately, as your "monitor mode" use case shows. The
>> overhead of parsing the packet twice is trivial compared to everything
>> else those apps are doing, so I don't think the gain is worth losing
>> that flexibility.
>>
>> So I definitely think using the regular epping is the right thing to do
>> here. Simon is looking into improving its reporting so it can be
>> per-subnet using a user-supplied configuration file for the actual
>> subnets, which should hopefully make this feasible. I'm sure he'll chime
>> in here once he has something to test and/or with any questions that pop
>> up in the process.
>>
>> Longer term, I'm hoping all of Herbert's other improvements to epping
>> reporting/formatting can make it into upstream epping, so LibreQoS can
>> just use that for everything :)
>>
>> -Toke
>>
>
>
> --
> Robert Chacón
> CEO | JackRabbit Wireless LLC <http://jackrabbitwireless.com>
> Dev | LibreQoS.io
>
> _______________________________________________
> LibreQoS mailing list
> LibreQoS@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/libreqos
>

[-- Attachment #2: Type: text/html, Size: 4665 bytes --]