From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id C30733B29D for ; Sat, 5 Nov 2022 12:44:59 -0400 (EDT) Received: by mail-ej1-x634.google.com with SMTP id f5so20500342ejc.5 for ; Sat, 05 Nov 2022 09:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jackrabbitwireless.com; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=4pDhORTTUCtjKGq1IKoNJtjEyIx49vSukr/McknxlB4=; b=Kf7jZuACU15RvQK1/cnIeMgv5jz2huFP0bFo3tcdFvBddq8WWnluB40DmXnEOsSF7O SsRkh1cq6Pdi6T8IIzR3Taf019NQj3FxfZ9u+8hrL+eCN1nYDH/tctSvzWqTFCNCz+bh M7igeJbf/w5YACRDXwD3nBGk+bL5oGCksRaww= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=4pDhORTTUCtjKGq1IKoNJtjEyIx49vSukr/McknxlB4=; b=0aZ1dHeyv24h9g5JKAcda8di7j6CzDWF4jBQmoXWovmbMG22YNRmhTXoMXhBERvC3M DK5WGfm/aOp6OmvTnbNucvSexoZnfLaqupw5kRgyChC8MjiTtAokZFfnJGpaAD+edYc9 xRmgX7TWzJNanlkP4tUFyha6AOorMNIv1SPDlWXkJ22JVi/ySJ8NLDe/3MGsd57J0yrL tgFUWqn51mqdOATdBncaBViwHgqrE/8A2f+5wYXcEEp/qWpjA7GUZAf1iM+AadAhGpkg KOneYarDthANzhMcl5/mzCwy+cyyoh4SRNQXfms3z2aUvOd6+dsUHQ3FAxFJCo4mBXPK TleQ== X-Gm-Message-State: ACrzQf3O6plorvNGodh4L+PQzAO+nZx5DFCPJw8z0bdE2j21MmTv27EU qKEtbk5yrHHfzZbBI2Z2sSVqDaYtxmRAqumrU9xsMSRKl6Tb2xcm X-Google-Smtp-Source: AMsMyM4Q1SFOPR1pjc5zBbftLH1PP6jQm85sCWkeRAyjeYD3XZYg43/b1tROnWZckJ3KQVOU0Z7IRTllO7cTvmjkbJI= X-Received: by 2002:a17:907:a429:b0:7a6:a48b:5e52 with SMTP id sg41-20020a170907a42900b007a6a48b5e52mr39289896ejc.411.1667666698125; Sat, 05 Nov 2022 09:44:58 -0700 (PDT) MIME-Version: 1.0 From: =?UTF-8?Q?Robert_Chac=C3=B3n?= Date: Sat, 5 Nov 2022 10:44:47 -0600 Message-ID: To: libreqos Content-Type: multipart/alternative; boundary="0000000000002560f605ecbbe905" Subject: [LibreQoS] Before/After Performance Comparison (Monitoring Mode) X-BeenThere: libreqos@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Many ISPs need the kinds of quality shaping cake can do List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2022 16:45:00 -0000 --0000000000002560f605ecbbe905 Content-Type: text/plain; charset="UTF-8" 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? --0000000000002560f605ecbbe905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was hoping to add a monitoring mode which could be = used before "turning on" LibreQoS, ideally before v1.3 release. T= his way operators can really see what impact it's having on end-user an= d network latency.

The simplest sol= ution 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 (Acces= s 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 us= e ePPing but I worry about throughput and the possibility of latency tra= cking being slightly different from cpumap-pping, which could limit the uti= lity of a comparison. We'd have to match IPs in a way that's a bit = more involved here.

Thoughts?
--0000000000002560f605ecbbe905--