Point taken! Before receiving this email I had started work on it. It's on a branch on GitHub now . 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 wrote: > Robert Chacón via LibreQoS 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 > > 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 Dev | LibreQoS.io