From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (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 58DC521F8F9 for ; Fri, 30 Oct 2015 05:26:02 -0700 (PDT) Received: by obbwb3 with SMTP id wb3so42712015obb.0 for ; Fri, 30 Oct 2015 05:26:02 -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=GPr7Ybor5f7bWehT/WBjYXxdjz0jISO1F6xecx4kNjE=; b=TtO5cDJZRVqu7/B/BUHu6S+Zoz2u0EeylPuHyhH9F4KqqnAq7WsayN5iIAlBMx7pvX kESH0RNo+baKVNzKxucNnUpbtOLoK0CfFa8MEYFlQyHxf1JHT6panB/vCyJNrDCGS355 tqhiPqcY4bKbaKIk3JqRd9NhNCVhC1+2VHArwhmeIaOFoRKqPufuRv3RVH3oyHjdQDUE C3rv5v9xkZFTmNmYp3Ri8sa51A0JgqaD57WreBpUYTsmsGNmzRr1Bx2HScGUtKfL3YHS 1QaWf8/IUXcKeDzESPkdgmD0+aA2T7kG3CNuulW2PbdGGjnUUfdZN7QvT3OHHoDtuk/8 71xA== MIME-Version: 1.0 X-Received: by 10.60.99.7 with SMTP id em7mr5387393oeb.63.1446207962189; Fri, 30 Oct 2015 05:26:02 -0700 (PDT) Received: by 10.202.61.133 with HTTP; Fri, 30 Oct 2015 05:26:02 -0700 (PDT) Date: Fri, 30 Oct 2015 08:26:02 -0400 Message-ID: From: Dave Taht To: cake@lists.bufferbloat.net, Felix Fietkau , Jesper Dangaard Brouer Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cake] kernel performance analysis in openwrt X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2015 12:26:25 -0000 So we are having issues with long term forwarding throughput in cake? or just cake on low end processors? Am confused. ? my original rrul tests of cake were at 100 mbit down/20 up, which is what comcast had upgraded me to. It worked where the fq_codel based system had not. If we have limits at 50/50, well, that wasn't my tested scenario and my observation is inbound rate limiting is more expensive than outbound by about 2x. i keep hoping someone will poke into an act_mirred replacement.... and ALL that said, performance on a system is a whole system issue - you need to profile the whole thing, over time, to see where the performance loss over a 5 minute run is coming from. My guess would be memory fragmentation, but I am old enough to profile, always. You could also be losing packets on the rx path... another bug entirely... it could be space aliens... and looking at the state of the codel algorithms is also important - but being out of cpu does heisenbug things. I used to use oprofile, but perf is all the rage. Perf can be cross compiled for openwrt, (it is in the kernel tree, you just need to go in there and tell it what compiler to use) however you generally need to nfs mount the kernel and fs in order to get a debuggable build. Also, in the case of the archer, the unaligned access hacks are uneeded, and you can actually compile for a later model cpu architecture. I learned an awful lot from jesper recently about how to use perf, but then it all exited my head. Perhaps there is a good tutorial out there? Or jesper can do a perf run with the current sch_cake codebase on his gear? :puppy dog eyes: Certainly once we are convinced the algorithms and implementations in cake are correct, then it is time to profile, and profiling earlier than that - like now - is good practice and may expose other issues elsewhere in the system. Jesper and I did take a look at it a few weeks back, and only found 3 hotspots (he probably has the data somewhere) - one of which was unnecessarily computing the hash twice, which I think is fixed now. Dave T=C3=A4ht I just invested five years of my life to making wifi better. And, now... the FCC wants to make my work, illegal for people to install. https://www.gofundme.com/savewifi