From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 3B11921F410; Thu, 26 Mar 2015 19:10:51 -0700 (PDT) Received: by obbgg8 with SMTP id gg8so61219801obb.1; Thu, 26 Mar 2015 19:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=H5df//u0N4lHNztEB6WRX+cG4oREv3X0b4pksBU1/Cw=; b=Jk7bd+cVRniNKV74utqGBHp3m9zxlSTVDU7RS1JMLMHm/vkvW4LVBQjAnNqRlwX96f fCk269FPI13Rn5srMSqQDH/m/KPOa/OhbbJLO2DwA01FsC1M2QsTT3/RFFJc/VKBu2+f v/FZGMXRLYsLUDxGRH3agbir81ysZ3tvD9BSA9nAfe6vk8ui9IjLJCrJ0L5yStYMcHpV 3UwYGkscHpBKgZBtXBHp4LPjCRsA0Sw4THZzwQj2rFMNtAUnRpUyw65600Ngt8OtOljX A4Q1utOUbTNNKlrR9R+8gqZnGLy+lpXUsNRiaODVQ+/jBE3HB2gpL1f696Lp/8Kh3EZK gUUg== MIME-Version: 1.0 X-Received: by 10.60.158.73 with SMTP id ws9mr14597193oeb.24.1427422250929; Thu, 26 Mar 2015 19:10:50 -0700 (PDT) Received: by 10.202.51.66 with HTTP; Thu, 26 Mar 2015 19:10:50 -0700 (PDT) Date: Thu, 26 Mar 2015 19:10:50 -0700 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" , Lorenzo Colitti , Felix Fietkau , Jesper Dangaard Brouer , Andrew McGregor , bloat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] some notes on the archer c7v2's suitability for make-wifi-fast 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: Fri, 27 Mar 2015 02:11:20 -0000 I took the archer c7v2 out for a set of test runs over the weekend. A) The good news: I couldn't crash it with a full workload nor overheat it with external temps at at 23C. I had tested the 3800 with external temp of 44C, and i would prefer to test any new product at that before wanting to use it here. It was easy to configure from my test build on snapon, only needing the addition of the kmod-ath10k package to have support for both radios. the gui seems to work well in that test build the "new" cake2 shaper/fq/codel qdisc (barely) managed to deal with 115mbit down and 12mbit up with 5% or so of cpu to spare with bridging and hostapd turned off. (htb + fq_codel fell apart at 90mbits.) I think cake can be improved quite a bit more and we really need to do some profiling to find other bottlenecks. having both an ath9k (fixable) and an ath10k (ac, probably not fixable) in the box is something of a plus also. B) The bad news: I didn't get around to testing wifi at all. I ran into an interesting problem, where testing it with full nat enabled, with no sqm-scripts, would peak at about 400 mbits on the rrul test, and: 0) If hostapd was running it would run a lot - cutting performance by about 50Mbits on the test runs. I think I posted the strace here already. 1) the queues for both eth1 and eth0 (wan and lan, respectively) would fill up - quite a lot, 100s of packets, on the rrul tests. Even though the base rate of the ethernet interfaces was a gigabit, the box could not service interrupts fast enough to clear out the device queues in either direction, thus engaging fq_codel as part of the overall cpu overload-handling mechanism to reduce the queue sizes somewhat. So I saw fairly long delays (7ms or more) when running at these speeds through the router. While reducing queue size when running out of cpu is a pleasing result, it also points to possible tuning options for napi, maybe adding xmit_more support in (or removing it entirely), in order to fully service all interrupts in one direction or another, and also compile options specific to the mips74k which has a long pipeline in particular, and so far as I know the archer has no issues (as the wndr3800 had) with unaligned access so we can turn off various hacks on that front. A linux feature I have long longed for is to do all timestamping (as well as calculating the 5 tuple) on the rx path, and the tx path leveraging that hash to fq on, and merely checking the rx entry time on dequeue for codel. (I know how hard this is to do, but it has become easier in more recent linux kernel versions. This would better account for running out of cpu in the router, and IMHO work better on cache-hot data on the rx side) I have 4 more routers in my stack, so far the two dlink ones were horrible, next up are the buffalo and belkin boxes, which I hope to get to next weekend. With a bit more testing of the wifi, the tplink archer c7v2 may prove out to be "not horrible" and a suitable candidate for make-wifi-fast, but I think the cpu limitation is kind of bad and would really like to try a quad mips or dual arm core. And normally I don't leave nat running, and left my dataset behind on the test box behind this router when I left for SF yesterday. :( --=20 Dave T=C3=A4ht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb