From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 7087F3B2A3 for ; Fri, 17 Mar 2017 15:15:28 -0400 (EDT) Received: by mail-wm0-x233.google.com with SMTP id n11so22845286wma.1 for ; Fri, 17 Mar 2017 12:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:reply-to :user-agent:mime-version:content-transfer-encoding; bh=nOD8Y/vxaG+eX6qCXMq48xZ7Vxl/mRQp99waexogKGg=; b=vRq0Psunr0CdagJzOs8CO9lO5YZzISzkxZTfRjb2YVqVHvl0m+4GwQH14yIUc3nb+u j9PUhGUn2nWOR0QemcdNIawoyZav+rFrPbPZKnsYATfJOlkz+WZbE8f9YdsPv6+yqfeF rNIgboC1duGObpPZx1T1GgOZkAeKg2Xu8dllXQdCfThH/ddU4ZU9jMnwgDGyuwXW7WVQ RXGGfFnBXxXH6u+Y6VTZWGOwOVLrgShcUgvH8JGNE971cCH5LgO47vn9TgaEU9OIKp4g PEtaJfns2gfpGxU5T/NwmMvW6Wg4G8LZ9e4QKDKIl46+50BLlUTWXC98DobSw9il5frK 9kiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:reply-to:user-agent:mime-version :content-transfer-encoding; bh=nOD8Y/vxaG+eX6qCXMq48xZ7Vxl/mRQp99waexogKGg=; b=m41v7TdGk0me6VrTMP+ZLNcXvOdCoCNINqQ9mse9UG8PKdrLeBX2nNWDNK1rlWFMKX M5a0rGSd5s9oxj8pJR2yQ5vrsZH4DULFLDZvth3gjceN8uStbqVz07/dKasm0Yqbicd9 FYfCpjoiICr0BRas3npvymKlNJNKHhhdwTv5pNrNxDJB3/lzxmCcCq3/TXqhMiBI6KLX LA7cP5aO5bqOBQmPOA3QAEs1oZX8WFPbkKBYJbvm4LaXf1iGEFIlMhKaq9SC9HoptL+2 IURRGFhyrQhjPs/3U5hLfwzyq3HxhQX90OoxktrW0WfLzrKq26I9nPODnF/bKwbldrS7 Z/9Q== X-Gm-Message-State: AFeK/H12H986xsaahc090sj1AxWZjrKuY2Dx0IkNj7wJgiFLbzXbHfZRJWBj5CJ+JbHHDQ== X-Received: by 10.28.224.69 with SMTP id x66mr4224921wmg.21.1489778127269; Fri, 17 Mar 2017 12:15:27 -0700 (PDT) Received: from [192.168.1.116] (cm149-53.liwest.at. [81.10.149.53]) by smtp.gmail.com with ESMTPSA id o63sm3636317wmo.30.2017.03.17.12.15.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Mar 2017 12:15:26 -0700 (PDT) From: xnor To: "bloat@lists.bufferbloat.net" Date: Fri, 17 Mar 2017 19:15:25 +0000 Message-Id: In-Reply-To: <57A046A6-C0F2-4209-93E5-CA728F4C64EE@gmx.de> References: <57A046A6-C0F2-4209-93E5-CA728F4C64EE@gmx.de> Reply-To: xnor User-Agent: eM_Client/7.0.27943.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Fri, 17 Mar 2017 19:15:28 -0000 Hey, please reply to the list address so that everyone can see it. > Just a guess, but I believe /sys/class/net/eth0.2/statistics/rx_bytes= =20 >shows the data before HTB/HFSC had a chance to touch the packets. Of course. So? HTB/HFSC don't shrink packages, and since I'm only doing=20 TCP and also use fq_codel it should shape ingress quite nicely to my=20 configured rate. > it would be interesting to repeat the tests but run tcpdump on the=20 >interface that delivers the traffic to the test machine on the internal= =20 >LAN. My prediction is that on that port you will pretty much see the=20 >18000Kbps you expect. The LAN is connected through eth0.1 which is part of a bridge interface=20 br-lan (this bridge is the only other interface with an IP address=20 besides eth0.2). With 160 download connections I've just measured (also included the=20 average bytes per packet, short bpp): eth0.2: 20.3 Mbps download (~1400 bpp) eth0: 21.6 Mbps download (~800 bpp), 19 Mbps upload (~780 bpp) eth0.1: 18 Mbps upload (~1490 bpp) br-lan: 18 Mbps upload (~1490 bpp) (all numbers approx. accurate to about +/- 0.1 Mbps) This is completely saturating the 20 Mbps link and ruins performance. I've tested to decrease the rate to make it work in the above scenario:=20 I had to back off with the rate to about 14 Mbps (!) because then, as=20 you can guess, measured eth0.2 bandwidth drops to below the 20 Mbps link= =20 speed. With less connections the measured eth0.2 bandwidth is closer to the=20 configured 18 Mbps and so works fine.. > This seems old, if your router is supported you might want to try lede= =20 >(https://lede-project.org/releases/17.01/start#), then you could also=20 >use the cake qdisc which has a few new tricks up its sleeve, nicer than= =20 >HTB and HFSC... I am planning to upgrade, but I highly doubt it'll help and it also=20 doesn't help me clear up the confusion with what is going on here. It's definitely shaping something. The question is: what?