From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 4657821F2AD for ; Sun, 29 Mar 2015 08:13:27 -0700 (PDT) Received: by lbcmq2 with SMTP id mq2so91798245lbc.0 for ; Sun, 29 Mar 2015 08:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xESId94ZWsTOg94U0C+lg4udwEmtjc8mJSFgl5PJ3u4=; b=bjaHYFtga2FbI2qCAJgGZGZyzTDvHmnDMuenYA/gtUvhkteXeZob6c5fOtCUYHO6WF 24BMfelq8p4q1gZFXE35aS2TmuIRQ/VoctMkwI8ylQHPEKe15YwjLiYFfH4q5u8p+1st E0vgn+PRLfwKwunzfFfLzRRH/go8hHF0Zsyq4fJNFigfJRzf625JDDfWxEia4AxlZCz/ mKg6KNeTYdzM6SJQr4uh3JVYSjdlUUGQPbesDhfXWK5ev/vYqozxuPDpxnB5kVJJUUUU NQA1QvhrZtqO8Yq3l6McdK04bRpKAkOiLxm+HjA6kggFTn/gW8rlguVfYwj6FTUk4jYf o3qA== X-Received: by 10.152.183.196 with SMTP id eo4mr24784756lac.22.1427642005667; Sun, 29 Mar 2015 08:13:25 -0700 (PDT) Received: from bass.home.chromatix.fi (87-95-163-98.bb.dnainternet.fi. [87.95.163.98]) by mx.google.com with ESMTPSA id lf3sm1528172lbc.2.2015.03.29.08.13.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 29 Mar 2015 08:13:24 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Jonathan Morton In-Reply-To: <9943A1F0-70B9-4162-9858-D04E223163B5@gmx.de> Date: Sun, 29 Mar 2015 18:13:22 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <91108D46-3990-4AAF-89AC-3965596C5CBF@gmail.com> References: <08BAF198-87C5-42B8-8899-53F34E47156E@gmail.com> <896FAE61-B45A-4F34-9449-5ADB82194DD9@gmx.de> <48350C2E-C33A-4534-84BC-5D56F4AAF0EA@gmail.com> <8AC58249-8199-405B-997A-E8F7285A34FB@gmx.de> <3615CBEA-5DC1-4722-9EE9-13B3570E8118@gmx.de> <91FFBFA0-0E87-4A57-AF6C-83C42AB10D1D@gmail.com> <9943A1F0-70B9-4162-9858-D04E223163B5@gmx.de> To: Sebastian Moeller X-Mailer: Apple Mail (2.2070.6) Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] archer c7 v2, policing, hostapd, test openwrt build X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 15:13:56 -0000 >> - Turning on HTB + fq_codel loses you 5%. >=20 > I assume that this partly is caused by the need to shape below the = physical link bandwidth, it might be possible to get closer to the limit = (if the true bottleneck bandwidth is known, but see above). > Downstream: (((1500 - 8 - 40 -20) * 8) * (98407 * 1000) / ((1500 + = 14 + 16) * 8)) / 1000 =3D 92103.8 Kbps; measured: 85.35 Mbps (dual = egress); 82.76 Mbps (IFB ingress) I interpret that as meaning: you have set HTB at 98407 Kbps, and after = subtracting overheads you expect to get 92103 Kbps goodput. You got = pretty close to that on the raw line, and the upstream number gets = pretty close to your calculated figure, so I can=92t account for the = missing 6700 Kbps (7%) due to link capacity simply not being there. = HTB, being a token-bucket-type shaper, should compensate for short = lulls, so subtle timing effects probably don=92t explain it either. >> Those 5% penalties add up. People might grudgingly accept a 10% loss = of bandwidth to be sure of lower latency, and faster hardware would do = better than that, but losing 25% is a bit much. >=20 > But IPv4 simple.qos IFB ingress shaping: ingress 82.3 Mbps = versus 93.48 Mbps (no SQM) =3D> 100 * 82.3 / 93.48 =3D 88.04%, so we = only loose 12% (for the sum of diffserv classification, IFB ingress = shaping and HTB) which seems more reasonable (that or my math is wrong). Getting 95% three times leaves you with about 86%, so it=92s a useful = rule-of-thumb figure. The more precise one (100% - 88.04% ^ -3) would = be 4.16% per stage. However, if the no-SQM throughput is really limited by the ISP rather = than the router, then simply adding HTB + fq_codel might have a bigger = impact on throughput for someone with a faster service; they would be = limited to the same speed with SQM, but might have higher throughput = without it. So your measurements really give 5% as a lower bound for = that case. > But anyway I do not argue that we should not aim at decreasing = overheads, but just that even without these overheads we are still a = (binary) order of magnitude short of the goal, a shaper that can do up = to symmetric 150Mbps shaping let alone Dave=92s goal of symmetric 300 = Mbps shaping. Certainly, better hardware will perform better. I personally use a = decade-old PowerBook for my shaping needs; a 1.5GHz PowerPC 7447 (triple = issue, out of order, 512KB+ on-die cache) is massively more powerful = than a 680MHz MIPS 24K (single issue, in order, a few KB cache), and it = shows when I conduct LAN throughput tests. But I don=92t get the chance = to push that much data over the Internet. The MIPS 74K in the Archer C7 v2 is dual issue, out of order; that = certainly helps. Multi-core (or at least multi-thread) would probably = also help by reducing context switch overhead, and allowing more than = one device=92s interrupts to get serviced in parallel. I happen to have = one router with a MIPS 34K, which is multi-thread, but the basic = pipeline is that of the 24K and the clock speed is much lower. Still, it=92s also good to help people get the most out of what they=92ve = already got. Cake is part of that, but efficiency (by using a simpler = shaper than HTB and eliminating one qdisc-to-qdisc interface) is only = one of its goals. Ease of configuration, and providing state-of-the-art = behaviour, are equally important to me. >> The point of this exercise was to find out whether a theoretical, = ideal policer on ingress might - in theory, mind - give a noticeable = improvement of efficiency and thus throughput. >=20 > I think we only have 12% left on the table and there is a need = to keep the shaped/policed ingress rate below the real bottleneck rate = with a margin, to keep instances of buffering =93bleeding=94 back into = the real bottleneck rare=85,=20 That=92s 12% as a lower bound - and that=92s already enough to be = noticeable in practice. Obviously we can=92t be sure of getting all of = it back, but we might get enough to bring *you* up to line rate. - Jonathan Morton