From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g1t0028.austin.hp.com (g1t0028.austin.hp.com [15.216.28.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp1.hp.com", Issuer "VeriSign Class 3 Secure Server CA - G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 37E2F20104F for ; Wed, 31 Aug 2011 08:55:06 -0700 (PDT) Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0028.austin.hp.com (Postfix) with ESMTP id 191191C079; Wed, 31 Aug 2011 15:55:04 +0000 (UTC) Received: from [16.89.244.213] (tardy.cup.hp.com [16.89.244.213]) by g1t0038.austin.hp.com (Postfix) with ESMTP id DF0A4300BC; Wed, 31 Aug 2011 15:55:03 +0000 (UTC) Message-ID: <4E5E5956.20006@hp.com> Date: Wed, 31 Aug 2011 08:55:02 -0700 From: Rick Jones User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Lightning/1.0b2 Thunderbird/3.1.12 MIME-Version: 1.0 To: Dave Taht Subject: Re: oprofiling is much saner looking now with rc6-smoketest References: <4E5D87DD.7040705@hp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat-devel X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2011 15:55:06 -0000 >> If this is inbound, and there is just plain checksumming and not anything >> funny from conntrack, I would have expected checksum to be much larger than >> copy. Checksum (in the inbound direction) will take the cache misses and >> the copy would not. Unless... the data cache of the processor is getting >> completely trashed - say from the netserver running on the router not >> keeping up with the inbound data fully and so the copy gets "far away" from >> the checksum verification. > > 220Mbit isn't good enough for ya? Previous tests ran at about 140Mbit, but due > to some major optimizations by felix to fix a bunch of mis-alignment > issues. Through the router, I've seen 260Mbit - which is perilously > close to the speed that I can drive it at from the test boxes. It is all a question of context. The last time I was in a context where 220 Mbit/s was high speed was when 100 BT first shipped or perhaps FDDI before that :) >> Does perf/perf_events (whatever the followon to perfmon2 is called) have >> support for the CPU used in the device? (Assuming it even has a PMU to be >> queried in the first place) > > Yes. Don't think it's enabled. It is running flat out, according to top. Well, flat-out as far as the basic OS utilities can tell. Stalled hardware manifests as CPU time consumed in something like top even though the processor may be sitting "idle," (in its context) twiddling its thumbs waiting on cache misses. Hence the question about PMU support. rick jones