From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1772F3B29D for ; Tue, 21 Apr 2020 14:23:16 -0400 (EDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id D63515C00A7 for ; Tue, 21 Apr 2020 14:23:15 -0400 (EDT) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Tue, 21 Apr 2020 14:23:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=althea.net; h= mime-version:message-id:date:from:to:subject:content-type; s= fm3; bh=ZOvZEzzQYDamCSSnwvJd8v/8wWKvQQNn0t34DRRXEB0=; b=SmbgWYPn 17tzQnDA/x/rRl+KBoJYHiavPcFdA4WCse8fpKnHoDHIe9X8vSNoWJWahYHn5v+k CFSwK/2nFc/jWNlUgKQHuwswwYS8sxj6ox6ec2vYPqE91j1TeNh+RWSW7nr7QE6O CnxxmyekvqX4N1RufQxUq0k9QXe1xu19j4FtiuYlmSu7gGbW4AiGMa09TIxKxDun 1BCg16ckL0Y/CIDt2GfGQU8bGrv3plAXViC5WK1AofrD9HO68zU8P9oT8giJOFDP UJ4KJvtwBw3wJHhSMiXeASkowR1WDydTD0JPlrnrh+wVdcc43zGSCVkk9+MaRrrO Q6NoUVW4179lyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=ZOvZEzzQYDamCSSnwvJd8v/8wWKvQ QNn0t34DRRXEB0=; b=UU6BX4tpNeohHDVDKybJioFPw92ts96YrXLLLeuA15fCC ued0x+/20WYht1x7dlBQ8Un8t3qcsS5oaKN9Rh86jfIhcJ54N49xO+pEg7px/8hy QmYbnTiDWySE5Q/BT1N05a5gON5R0MGziDNJpP43gjdmGYY4RHfquT4vjxjyPw9A HLFFQyBy2oAwm+VeYli7eekWhJyBaVlIJU/+6cA3Y6/3Aw7MvSUgp74zkJ4JU2J2 bNKSUakO94U/w6Op4i1IanLekLfKKUa0hDkAdTA1hi75zyKqI9rxDsP/UUh+UHyx itwVn+11fAuXpNAfnXuYW9bgaZQyCA1XeShXcxHCg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeehgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedflfhushhtihhnucfmihhlphgrthhrihgtkhdfuceojhhushht ihhnsegrlhhthhgvrgdrnhgvtheqnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepjhhushhtihhnsegrlhhthhgvrgdrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 90D39C200A5; Tue, 21 Apr 2020 14:23:15 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-351-g9981f4f-fmstable-20200421v1 Mime-Version: 1.0 Message-Id: Date: Tue, 21 Apr 2020 14:22:54 -0400 From: "Justin Kilpatrick" To: cake@lists.bufferbloat.net Content-Type: text/plain Subject: [Cake] Advantages to tightly tuning latency X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 21 Apr 2020 18:23:16 -0000 I have a frequently changing link I'm using automated tools to monitor and tune using Cake. Currently I'm only tuning bandwidth parameter using latency and packet loss data. My reading of the codel RFC seems to say that trying to tune the 'interval' value using known path and link latency won't provide any advantages over just tuning the bandwidth parameter. Obviously codel is just one part of the Cake setup and I'm wondering if there are any advantages I'm missing by not providing this extra input using data I already gather. Thanks! -- Justin Kilpatrick justin@althea.net