> That's a lot to play with, so I'm taking my time. My gut likes the A/B switch, currently. Take your time, I'm just thrilled to see this working so well so far. > I could feel the difference at my desk; fire up a video while a download was running, and it simply "felt" like it responded better. TCP RTT times are the best measure of "feel" I've found, so far. I've experienced the same when our network switched from LibreQoS using fq_codel to LibreQoS using CAKE. Really hard to quantify it but the "snappiness" or "feel" is noticeable to end-users. > We've tended to go with "median" latency as a guide, rather than mean. Thanks to monitoring things beyond our control, some of the outliers tend to be *really bad* - even if the network is fine. There's literally nothing we can do about a customer trying to work with a malfunctioning system somewhere (in space, for all I know!) True. And it can be sort of helpful for troubleshooting WiFi latency issues and bottlenecks inside the home and such. > "monitor only" mode Perhaps we can use ePPing just for this aspect? Or instead we could use cpumap-pping but with all HTB classes set to high rates (no plan enforcement) and no CAKE leafs. > How about the idea of "metaverse-ready" metrics, with one table that is preseem-like and another that's Good idea. I've now added both a standard (preseem like) table and "metaverse-ready" table of Node (AP) TCP Latency on the InfluxDB template. On Sun, Oct 30, 2022 at 8:21 PM Dave Taht via LibreQoS < libreqos@lists.bufferbloat.net> wrote: > How about the idea of "metaverse-ready" metrics, with one table that is > preseem-like and another that's > > blue = < 8ms > green = < 20ms > yellow = < 50ms > orange = < 70ms > red = > 70ms > > _______________________________________________ > LibreQoS mailing list > LibreQoS@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/libreqos > -- Robert Chacón CEO | JackRabbit Wireless LLC Dev | LibreQoS.io