From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id B40D63B2F5 for ; Thu, 7 Apr 2016 12:40:49 -0400 (EDT) Received: by mail-oi0-x231.google.com with SMTP id w85so106055467oiw.0 for ; Thu, 07 Apr 2016 09:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=GC3QrzUev31M+ssXahke10U5jfapQ4tpL2hnFHfQ86o=; b=MJuIZduqj6JCK0bmSUfJx28wxeEqqoUM/HrCBnSdnGcQOxm50NuRgT2Fb0z8W5tjco Qo3C5pRks99VrjdOftOtkMMMYbt8qsTARx35eg7zWUaMK/IKkS5AYOTcuQPjXm9QY+uf D59d8Mum9HvdL0DPRM+S3mwnv9kfJWrY+NerIWU+31/e3yewk7U7JbwtdHa/VSC9vrxS dToR68qrW4kf/cmkDgfmfflNlxyEoU5A0kGpPvbSUlr6bo6vY+Kn1BdvdtXTd+po/TXN bt6Cy5T9jMcRiEQ5i/ZqEkXW6EKz9PWqyxWVESN0cQOUWC8SGFfw2+B73NsTvl0KJM+P mM9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=GC3QrzUev31M+ssXahke10U5jfapQ4tpL2hnFHfQ86o=; b=hd9J4x/1w2rEai6csoakH2Jwl6GlOs/70vDs0N9g3j0s1myIgec26AYR/8aT2M3eFK wbjUU74PyyuAdlcaqU7mRiFWjcL7oaO86DD3ayn97MtpNjXUGPFFuDgWBh591/mikpnZ kuuZWv3kAdGyvuoen7JbQ3nwzZhNuKwWH/JdoAEo/DuQyUeKN0QPcA+NHmAYeZedIpN3 v12zP1fqmp7nC9FMt2oNgiNbcem5KRJzqCIESUVWH1vlerYfZsJX22t+RJ5c8Fn4toys KVnVGkwKkv7gip6dT1z5Bhn1ctrCL8gNJUUH5XlB61dBM9HxTC0q00CX5vO8vSma992n XC3Q== X-Gm-Message-State: AD7BkJIZuXBgfk2ekDcAR20UX1K+vIlT9QaZMOj0snhbrw5CHrTrFvZU77npZ3PX3mwkdOyO574XLMnJoTGeXA== MIME-Version: 1.0 X-Received: by 10.157.57.131 with SMTP id y3mr1798247otb.169.1460047249044; Thu, 07 Apr 2016 09:40:49 -0700 (PDT) Received: by 10.202.79.215 with HTTP; Thu, 7 Apr 2016 09:40:48 -0700 (PDT) In-Reply-To: <056D9AAF-85E2-4849-A3EC-4CE77276DF24@gmx.de> References: <57066793.5050608@gmail.com> <056D9AAF-85E2-4849-A3EC-4CE77276DF24@gmx.de> Date: Thu, 7 Apr 2016 09:40:48 -0700 Message-ID: From: Dave Taht To: moeller0 Cc: Richard Smith , "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cerowrt-devel] Linksys wrt1900acs rrul traces 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: Thu, 07 Apr 2016 16:40:49 -0000 There are multiple hardware queues on this ethernet interface but not enough to avoid collisions. The driver has really deep queues. The driver itself is buggy and lacks BQL. My own take on it was to use the hardware queues for different forms of QoS, rather than spreading flows across it. There was some work on getting BQL to work on it; that stalled out. On Thu, Apr 7, 2016 at 9:16 AM, moeller0 wrote: > Hi Richard, > >> For these tests I had the inbound and outbound limits set to 975000 kbps= . 975000 was somewhat arbitrary. I wanted it below 1Gbps enough that I co= uld be sure it was the router as the limit but yet fast enough that I would= be able to see the peak transfer rates. > > All of the following might be old news to you, but please let me elaborat= e for others on this list (well, most folks here know way more about these = things than I do). > I believe Gbit ethernet is trickier than one would guess, the 1 G= bit rate contains some overhead that one typically does not account for. He= re is the equivalent on-the-wire size of a full MTU non-jumbo ethernet fram= e: > Layer =E2=80=9C1+": 1500 (payload pMTU) + 6 (dest MAC) + 6 (src MAC) + 2 = (ethertype) + 4 (FCS) + 7 (preamble) + 1 (start of frame delimiter) + 12 (i= nterframe gap)) =3D 1500+6+6+2+4+7+1+12 =3D 1538 > =E2=80=9DEquivalent=E2=80=9D in that the interframe gap is not really use= d, but filled with silence but it has the duration one would need for 12 by= tes. > > The kernel, if left to its own devices, will only account for 14 of 38 ov= erhead bytes. But that means that each packet will carry an additional 24 b= ytes of unaccounted for size that still needs to be transferred: > > 975000 * (1538/1514) =3D 990455.746367 (which still is below the 1GBit La= yer1+ ceiling that GbE has). At 985000 * (1538/1514) =3D 1000614.26684 you= would already have slowly caused the NIC=E2=80=99s buffer to fill ;) > Luckily sqm-scripts will allow you to specify any additional per-packet o= verhead so just set this to 24 and things should just work out I believe. > > > Best Regards > Sebastian > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel