From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp113.iad3a.emailsrvr.com (smtp113.iad3a.emailsrvr.com [173.203.187.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 24F183B260 for ; Sun, 4 Dec 2016 14:41:06 -0500 (EST) Received: from smtp39.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EB23E56FF; Sun, 4 Dec 2016 14:41:05 -0500 (EST) Received: from app42.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp39.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DD8DC566F; Sun, 4 Dec 2016 14:41:05 -0500 (EST) X-Sender-Id: dpreed@reed.com Received: from app42.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sun, 04 Dec 2016 14:41:05 -0500 Received: from reed.com (localhost [127.0.0.1]) by app42.wa-webapps.iad3a (Postfix) with ESMTP id CD7ED20086; Sun, 4 Dec 2016 14:41:05 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Sun, 4 Dec 2016 14:41:05 -0500 (EST) Date: Sun, 4 Dec 2016 14:41:05 -0500 (EST) From: dpreed@reed.com To: "Jonathan Morton" Cc: "Matt Taggart" , cerowrt-devel@lists.bufferbloat.net MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <20161204082535.35E8C229@taggart.lackof.org> X-Auth-ID: dpreed@reed.com Message-ID: <1480880465.82881490@apps.rackspace.com> X-Mailer: webmail/12.6.3-RC Subject: Re: [Cerowrt-devel] Intel latency issue X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 04 Dec 2016 19:41:06 -0000 The language used in the article seems confused. However, since firmware so= metimes means software (the OS kernel, for example) and this is "lag under = load", it's barely possible that this is bufferbloat of a sort, it seems. W= ould we be surprised?=0A=0A200 ms. can also be due to interrupt mishandling= , recovered by a watchdog. It's common for performance to reduce interrupt = overhead by switching from interrupt driven to polled while packets are arr= iving at full rate and then back again when the traffic has a gap. If you d= on't turn interrupts back on correctly (there's a race between turning on i= nterrupts and packet arrival after you decide and before you succeed in tur= ning on interrupts), then you end up waiting for some "watchdog" (every 200= ms?) to handle the incoming packets.=0A=0AThe idea that something actually= runs for 200 ms. blocking everything seems to be the least likely situatio= n - of course someone might have written code that held a lock while waitin= g for something or masked interrupts while waiting for something. But actua= lly executing code for 200 ms.? Probably not.=0A=0A=0A=0A=0A=0A=0AOn Sunday= , December 4, 2016 3:27am, "Jonathan Morton" said:= =0A=0A> =0A>> On 4 Dec, 2016, at 10:25, Matt Taggart wrot= e:=0A>>=0A>> "Modems powered by Intel's Puma 6 chipset that suffer from bur= sts of=0A>> game-killing latency include the Arris Surfboard SB6190, the Hi= tron=0A>> CGNV4, and the Compal CH7465-LG, and Puma 6-based modems rebadged= by=0A>> ISPs, such as Virgin Media's Superhub 3 and Comcast's top-end Xfin= ity=0A>> boxes. There are other brands, such as Linksys and Cisco, that use= the=0A>> system-on-chip that may also be affected."=0A> =0A> I do have to = ask: the Atom isn=E2=80=99t very powerful, but WTF is it doing for=0A> 200m= s every few seconds?=0A> =0A> - Jonathan Morton=0A> =0A> _________________= ______________________________=0A> Cerowrt-devel mailing list=0A> Cerowrt-d= evel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/listinfo/cerow= rt-devel=0A> =0A