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 . > 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 > > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos >