From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (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 03AC721F2B5 for ; Tue, 2 Sep 2014 03:06:02 -0700 (PDT) Received: by mail-qg0-f49.google.com with SMTP id j107so6123757qga.8 for ; Tue, 02 Sep 2014 03:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aenertia.net; s=dkimaenertianet; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=R0N11tCFJBd9PUFm6+nU+bintVQ+wkNDGiM/zDPfTcY=; b=MwvxS9CpVVLvdWlzX6muf0BxriCn+67yhMuqbVdsMHyPZJqDtkr7cJcY5l+THfImPz YqBAUPpDNhJeQ4S+aoQsP6SlKpKX7EvGIZUKmEvv3AMd8toiirjprtAT8NEskydsMdrg K6HL2XZLkwrBG9iPRKXV3QJy5bbqgXoh0pqXY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=R0N11tCFJBd9PUFm6+nU+bintVQ+wkNDGiM/zDPfTcY=; b=VLJaFtdieStMgrFfmXFruLijDaxhQo5hVsD8M92eHWc10bB+pey3orj5O8mqG22OX2 j5QFP55zs7G9tDABttv0pivCic14eMLQ6fQdRvh4HrtQKm/3ZuVzaJVRyV6b9hMi/BU+ 6Qsd8p4h8pGS8j21IfeSmFn0rE6j09+7TTUSklLPyshndzy9g7gCBgip7jDs03AmtY5q XXHWjhM9VFWdHHEvHTxeK+06WbVUpy3BxvoiJkylmXti16Th4VWvBXClsksAWcjlaS5V 03GD8TSB4xdNUS80EOiSmfZFNMt2A/PqgP4/yjfESgbhxBXX1LLTLvYBwZQkC8bGHwFN OHzQ== X-Gm-Message-State: ALoCoQlCpVRvrat/RIvQyZwZvHEw2uiLQF9a4H2ElzQBfW759+6FgrKA3Vyl05u3VFrlNPmZwwJO X-Received: by 10.140.22.243 with SMTP id 106mr50083334qgn.86.1409652362088; Tue, 02 Sep 2014 03:06:02 -0700 (PDT) MIME-Version: 1.0 Sender: aenertia@aenertia.net Received: by 10.96.44.134 with HTTP; Tue, 2 Sep 2014 03:05:42 -0700 (PDT) In-Reply-To: References: <87ppfijfjc.fsf@toke.dk> <4FF4917C-1B6D-4D5F-81B6-5FC177F12BFC@gmail.com> <4DA71387-6720-4A2F-B462-2E1295604C21@gmail.com> <0DB9E121-7073-4DE9-B7E2-73A41BCBA1D1@gmail.com> From: =?UTF-8?Q?Joel_Wir=C4=81mu_Pauling?= Date: Tue, 2 Sep 2014 22:05:42 +1200 X-Google-Sender-Auth: wRTS1CCZ3oGCgXAZ6XzUw1OLBoY Message-ID: To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] [Bloat] Comcast upped service levels -> WNDR3800 can't cope... 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: Tue, 02 Sep 2014 10:06:03 -0000 https://wikidevi.com/wiki/Securifi_Almond%2B On 2 September 2014 22:05, Joel Wir=C4=81mu Pauling wro= te: > On a somewhat related note - I've just received my NZ/AU Region > Almond+ which is an arm9 Dual core router based on the Cortina CSC SoC > : > > https://www.cortina-systems.com/product/digital-home-processors/16-produc= ts/996-cs7542-cs7522 > > More details : > > On 2 September 2014 21:27, Jonathan Morton wrote: >> >> On 2 Sep, 2014, at 1:14 am, Aaron Wood wrote: >> >>>> For the purposes of shaping, the CPU shouldn't need to touch the major= ity of the payload - only the headers, which are relatively small. The bul= k of the payload should DMA from one NIC to RAM, then DMA back out of RAM t= o the other NIC. It has to do that anyway to route them, and without shapi= ng there'd be more of them to handle. The difference might be in the data = structures used by the shaper itself, but I think those are also reasonably= compact. It doesn't even have to touch userspace, since it's not acting a= s the endpoint as my PowerBook was during my tests. >>> >>> In an ideal case, yes. But is that how this gets managed? (I have no = idea, I'm certainly not a kernel developer). >> >> It would be monumentally stupid to integrate two GigE MACs onto an SoC, = and then to call it a "network processor", without adequate DMA support. I= don't think Atheros are that stupid. >> >> Here's a more detailed datasheet: >> http://pdf.datasheetarchive.com/indexerfiles/Datasheets-SW6/DSAS= W00118777.pdf >> >> "Another memory factor is the ability to support multiple I/O operations= in parallel via the WNPU's various ports. The on-chip SRAM in AR7100 WNPUs= has 5 ports that enable simultaneous access to and from five sources: the = two gigabit Ethernet ports, the PCI port, the USB 2.0 port and the MIPS pro= cessor." >> >> It's a reasonable question, however, whether the driver uses that suppor= t properly. Mainline Linux kernel code seems to support the SoC but not th= e Ethernet; if it were just a minor variant of some other Atheros hardware,= I'd have expected to see it integrated into one of the existing drivers. = Or maybe it is, and my greps just aren't showing it. >> >> At minimum, however, there are MMIO ranges reported for each MAC during = OpenWRT's boot sequence. That's where the ring buffers are. The most the = CPU has to do is read each packet from RAM and write it into those buffers,= or vice versa for receive - I think that's what my PowerBook has to do. I= deally, a bog-standard DMA engine would take over that simple duty. Either= way, that's something that has to happen whether it's shaped or not, so it= 's unlikely to be our problem. >> >> The same goes for the wireless MACs, incidentally. These are standard a= th9k mini-PCI cards, and the drivers *are* in mainline. There shouldn't be= any surprises with them. >> >>> If the packet data is getting moved about from buffer to buffer (for in= stance to do the htb calculations?) could that substantially change the pro= cessing load? >> >> The qdiscs only deal with packet and socket headers, not the full packet= data. Even then, they largely pass pointers around, inserting the headers= into linked lists rather than copying them into arrays. I believe a lot o= f attention has been directed at cache-friendliness in this area, and the M= IPS caches are of conventional type. >> >>>> Which brings me back to the timers, and other items of black magic. >>> >>> Which would point to under-utilizing the processor core, while still ha= ving high load? (I'm not seeing that, I'm curious if that would be the case= ). >> >> It probably wouldn't manifest as high system load. Rather, poor timer r= esolution or latency would show up as excessive delays between packets, dur= ing which the CPU is idle. The packet egress times may turn out to be quan= tised - that would be a smoking gun, if detectable. >> >>>> Incidentally, transfer speed benchmarks involving wireless will certai= nly be limited by the wireless link. I assume that's not a factor here. >>> >>> That's the usual suspicion. But these are RF-chamber, short-range lab = setups where the radios are running at full speed in perfect environments..= . >> >> Sure. But even turbocharged 'n' gear tops out at 450Mbps signalling, an= d much less than that is available even theoretically for TCP/IP throughput= . My point is that you're probably not running *your* tests over wireless. >> >>> What this makes me realize is that I should go instrument the cpu stats= with each of the various operating modes: >>> >>> * no shaping, anywhere >>> * egress shaping >>> * egress and ingress shaping at various limited levels: >>> * 10Mbps >>> * 20Mbps >>> * 50Mbps >>> * 100Mbps >> >> Smaller increments at the high end of the range may prove to be useful. = I would expect the CPU usage to climb nonlinearly (busy-waiting) if there'= s a bottleneck in a peripheral device, such as the PCI bus. The way the ke= rnel classifies that usage may also be revealing. >> >>> Heck, what about running HTB simply from a 1ms timer instead of from a = data driven timer? >> >> That might be what's already happening. We have to figure out that befo= re we can work out a solution. >> >> - Jonathan Morton >> >> _______________________________________________ >> Cerowrt-devel mailing list >> Cerowrt-devel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel