From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 0FB5C21FAA8 for ; Fri, 14 Aug 2015 07:52:51 -0700 (PDT) Received: by lbbsx3 with SMTP id sx3so46959437lbb.0 for ; Fri, 14 Aug 2015 07:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LJNPO83bCtDA4elPazD2U3ISDryUSKAJb5CbG1svik0=; b=iZCuU6bhlpaZJlgcVcC1tz3NE8cLxuIYypAjrp6q1Xr0SMOMfg7A31RkaLcZSsLGWl UYVI1AofADj6mjJc0vLROmLDcH5P9K6pfLCmL9zs1RobjUBp7JRYlgZI/0brRMxzOwfT yqny7U964I0xgNNOfuvQ6o1Ci1yA4Z0hqOfJM163SqFQ3+ANtjVua+Npel7xjz2xKCRg VmeQXx7udMGtH9Vvj+DPIn+LWbOBrz3IehFJK5Qy9SBNKMP4Xjfpf97aNfKlqsLxhXyH ROIn3++7iG3h4AxagfzmpKPtGkP0G9UAD61Wt9yK5FEybI6sAcYZAZoKp1zRWUHfj6cy rnJw== X-Received: by 10.152.181.5 with SMTP id ds5mr44092171lac.60.1439563969529; Fri, 14 Aug 2015 07:52:49 -0700 (PDT) Received: from bass.home.chromatix.fi (176-93-44-124.bb.dnainternet.fi. [176.93.44.124]) by smtp.gmail.com with ESMTPSA id c5sm1519180lae.47.2015.08.14.07.52.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Aug 2015 07:52:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: Jonathan Morton In-Reply-To: <55CDE8E3.4080207@student.kit.edu> Date: Fri, 14 Aug 2015 17:52:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9EEB70FD-2B99-49AC-8C58-A74CFC0DEFC2@gmail.com> References: <55AD2695.8050605@kit.edu> <07D540E8-1184-4DBD-B372-40C55A485C40@gmail.com> <55CDE8E3.4080207@student.kit.edu> To: Polina Goltsman X-Mailer: Apple Mail (2.2102) Cc: Roland Bless , codel@lists.bufferbloat.net, aqm@ietf.org Subject: Re: [Codel] [aqm] Codel's count variable and re-entering dropping state at small time intervals X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Aug 2015 14:53:14 -0000 > 1. in Cake, count saturates at 2^32-1, am I right = (https://github.com/dtaht/sch_cake/blob/master/codel5.h#L352). >=20 > could it make sense to saturate count when interval/sqrt(count) and = interval/sqrt(count+1) are indistinguishable in timer resolution? Actually it saturates at 2^16-1, since count is declared as u16 (though = it could reasonably be a wider type, too). At that point, there are about 2560 drops (or marks) per second; if it = did go up to 2^32-1, that would be 655360 drops/marks per second. Linux = timers on modern hardware generally have microsecond resolution or = better, so there is no reason to saturate early even in the latter case. > 2. I found three more changes from the original Codel: >=20 > 2.1 Line292: if (sojourn_time < target || queue is empty) instead of = (sojourn_time < target || there is less than MTU bytes in the queue). >=20 > was it changed because queue_length_in_bytes < MTU causes sojourn_time = < target ? We found no reason to special-case the last packet in the queue, so we = simplified the code by removing it. Detecting MTU (via the = =E2=80=9Cmaxpacket=E2=80=9D statistic) was rather fragile in the face of = GRO and GSO, with some common hardware regularly producing 64K = aggregates. Instead of special-casing the last packet, Cake constrains the target to = 1.5 hardware MTUs (detected via the interface API, not via maxpacket) at = the shaped rate. This has more nearly the desired effect. > 2.2. Line 304: >=20 > else if (vars->count > 1 && now - vars->drop_next < 8 * interval) { > /* we were recently dropping; be more aggressive */ > return now - vars->first_above_time > > codel_control_law(now, interval, vars->rec_inv_sqrt); > } >=20 > 2.3. Line 308: >=20 > else if (((now - vars->first_above_time) >> 15) * ((now - = codel_get_enqueue_time(skb)) >> 15) > threshold) { return true; }. > This line is explained in this email from Cake mailing list: = https://lists.bufferbloat.net/pipermail/cake/2015-May/000227.html >=20 >=20 > My question is - are these changes valid for a standalone Codel or are = they specifically made to optimize Cake's scheduler? I believe they could be. The intent is to bias interval according to = how quickly the queue is growing, so as to react more aggressively to = slow-start=E2=80=99s rapid growth than to congestion-avoidance slow = growth. It might be worth testing in a standalone context. - Jonathan Morton