From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 0AC8E21F461 for ; Mon, 2 Nov 2015 16:55:23 -0800 (PST) Received: by pacfv9 with SMTP id fv9so1743317pac.3 for ; Mon, 02 Nov 2015 16:55:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber_org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; bh=FRsPcryqrqRX/3403RYflazh2W/G2E4Pzh2ri1TcPzE=; b=UmzvWyYTrXawN0K7XO+p2y5eWryRgQ4hug+z8tkpCmLquKMKmcug3ZHGGxelHuusVs 9DDr/HJqGVvFyfeqDiTqG9dNmgvLdNYNfkSMnFHMy71d869ec6FoABXL642hFt+PssGl yaNj97FIwpYKWkmV7jYHTNg2k8FDhUjlYkV8iKuti6pSatMLMG6mWydps1jKv8ms1nQ1 B5oSW2UkSH7c5JUJAJlLpNvF7RBL8Kb0Zs/+opXzGUr15fRLJHeaua+e8lQOX8SGDm+P wXrPgxH1HAn2Nox7/iu/qx7Sp1i+FHj72CwxAmsFIgdbg6nq2aqTa4msafQ7PCFv8KAg BwSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=FRsPcryqrqRX/3403RYflazh2W/G2E4Pzh2ri1TcPzE=; b=diPSrRB1DDUWNpWUxPk/4XnvqM01JZK35kErnVV+e0ltSeqrEq87AAzj4T+pXRaE5U SIlMAds7JrfbiqLNyi2W4FV05qBZBgfQxYNSNz6ubv6OuJiCRLLjO+XgunHdBpZVX2dg T5UcCqdnEw+hFGZd/pYlm83lTHTv8gYE2URsiER0IrI/Tv5ySHS8uBI+E1ZsLB1P89f9 vLI92kSCcC+vW1BCW2+J89hIE+1EqHt18N1XZhd0HcIm6OXj24+2b3vX7El0ArNu4bFs ZkHtFY9O4dCl3EkFbOvG5yWjI6qdWcsjc3vC6Gr+8w1+NFOAg0aYlO07uKiNFmHgUWXe ISlA== X-Gm-Message-State: ALoCoQkC2SGw0GxKrNeHzFsJc4AypttKca8BOhOb+vOZnLKqFu8Yeom1HurUM0aWRxp+SS/w3D7c X-Received: by 10.68.132.131 with SMTP id ou3mr30457384pbb.92.1446512122751; Mon, 02 Nov 2015 16:55:22 -0800 (PST) Received: from xeon-e3 (static-50-53-82-155.bvtn.or.frontiernet.net. [50.53.82.155]) by smtp.gmail.com with ESMTPSA id ey17sm26280118pac.26.2015.11.02.16.55.22 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Nov 2015 16:55:22 -0800 (PST) Date: Mon, 2 Nov 2015 16:55:32 -0800 From: Stephen Hemminger To: Jesper Dangaard Brouer Message-ID: <20151102165532.2e714f77@xeon-e3> In-Reply-To: <20151029120038.03f09749@redhat.com> References: <20151029120038.03f09749@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] the meta problem of memory, locks, and multiple cpus 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: Tue, 03 Nov 2015 00:55:46 -0000 On Thu, 29 Oct 2015 12:00:38 +0100 Jesper Dangaard Brouer wrote: > On Thu, 29 Oct 2015 10:08:34 +0100 > Dave Taht wrote: > > > The real problem A) that I wish we could solve at the qdisc layer > > > > is that we could size everything more appropriately if we actually > > *knew* the physical link rate in many cases. It is *right there* in > > the sys filesystem for ethernet devices, if only there was some way to > > get at it, and get notifications if it changed.... or merely to know > > the underlying operating range of the device at qdisc init time. It is > > dumb to allow 50MB of memory for a 10mbit device just to make the > > 10GigE folk happy. > > Well, do you really need to know the link rate? One of the lessons > learned from codel (by Kathleen/Van) is that we should not trie to > measure the link rate, but instead simply look at the time spend in > queue. Why not measure the egress rate like PIE? It is right there in the same code. Also many devices (like wifi) can't report real link rate.