From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 9D8233BA8E for ; Sat, 18 Mar 2017 11:46:58 -0400 (EDT) Received: by mail-lf0-x231.google.com with SMTP id z15so42683970lfd.1 for ; Sat, 18 Mar 2017 08:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RP6RdDdcWqgNQuHU7acai/uamhhtEhuYPWGQO+BjsFY=; b=tQPoE2FbEQjHgvRT17hVJL2wTFAGjoQ5ZEar1GSGvCL5cp2YixZQ8y8JEZenKB0Moh PujBYhbOH4mcsrQFqXFFP0X0twFTFI+KCxwWnDqCDyJk4Ku2W7dxoe/sjYS9bmFPs375 eYY9T+0Dn0aMMc4owEm2Ka+GRG/6aSvYgSVBHX/qZvbeMy/Xc23Rouf6gNa8ijiY5Zxm TBjgXPv4Jwyw2Y+/7lNihpVSO0/1mbxLKxwEKeWyVqVqCTG5MbRDMGp0aFtDp2SP3u+B Co0wChbMAyhlGifXjVEYBX7/inZ1r7/O8c83kNvK5C96rWlc/YPzieMbdTMShihATKEu NyKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=RP6RdDdcWqgNQuHU7acai/uamhhtEhuYPWGQO+BjsFY=; b=AthH+Lb97DOShR5HX31OBWfryK/S8dcEd8ERDSwOFN0jzdmK37Jh6I0G3o/8CL6xUp 3e7QQvWhz1eXAvzJSMmmGBlWXFlw9epPjpQ1dQ4+TFkpd2x1pMlPgEd7+VIz0EQb0v74 bZWG09R5ji27c9agybukw23yBqe4q58JCI/0yCj7CWA8T6gac886N7UA47f6t41VODpR 8mlqlBkZyfteE+LXmfhgDu9iJbT2Hx7YC/+ETgfW0uTSbhcrhNLmmQ2LzfUXxD7b5ty0 drs+rXmrqCWrwofdUcZM0q0eYNiisS9leZjEBKymILUY1wpgiPLi8YgzSBEb6b/ngLkN HV1A== X-Gm-Message-State: AFeK/H1U4bQ2PP0f8hHVrfhhxjAVXx+n1zqPRiu8dHJe9lsA2xXLoDW9YhUGtSpIqXJtlQ== X-Received: by 10.46.21.76 with SMTP id 12mr270869ljv.98.1489852017429; Sat, 18 Mar 2017 08:46:57 -0700 (PDT) Received: from [192.168.100.16] (37-219-206-78.nat.bb.dnainternet.fi. [37.219.206.78]) by smtp.gmail.com with ESMTPSA id w78sm2048712lfi.23.2017.03.18.08.46.56 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 18 Mar 2017 08:46:56 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Sat, 18 Mar 2017 17:46:54 +0200 Cc: "bloat@lists.bufferbloat.net" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1489785303.28631.318.camel@edumazet-glaptop3.roam.corp.google.com> To: xnor X-Mailer: Apple Mail (2.3124) Subject: Re: [Bloat] Inaccurate rates with HTB/HFSC+fq_codel on router due to VLAN? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Mar 2017 15:46:58 -0000 > On 18 Mar, 2017, at 17:34, xnor wrote: >=20 > If I understood it correctly, and very simplified speaking, right now = a queue is filled with link speed and drained by a configured bandwidth. = As the pressure in a queue rises, packets will be dropped/marked to = reduce pressure to some tolerable level. >=20 > Why not measure ingress rate (averaged over a window related to the = configured rtt) and increase pressure if the ingress rate surpasses the = configured bandwidth? If the ingress rate is higher than the shaped rate, the queue will fill, = and this will automatically trigger higher AQM activity. There is no = need to actually measure ingress rate to achieve this, and that=E2=80=99s = not what autorate_ingress is meant for. What you should be looking for is the number of dropped and marked = packets. Marked packets (which appear due to AQM activity on ECN-capable traffic) = continue through to the receiver and inform it directly of congestion, = which is then communicated to the sender, which in turn is supposed to = reduce its congestion window to suit. Dropped packets represent the *difference* between the ingress rate and = the rate actually reaching the receiver, which is informed about = congestion by detecting these packets=E2=80=99 *absence*. It must then = tell the sender to re-send those packets, resulting in *more* ingress = traffic for a given goodput. A useful experiment would be to reduce your shaped rate until you see an = effect on goodput (measured at the receiver) and ingress rate. For = example, configure for 5Mbps down and 1Mbps up, and see what you = actually get. On some hardware we have seen a perplexing doubling of the configured = shaped rate. This is not a bug in the shaper, but may be due to bad = timer hardware which runs faster than realtime. In this case you might = see *no* marking and dropping when configured for the full rate = intended. - Jonathan Morton