From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 23FC73B29E for ; Wed, 12 Apr 2017 09:44:27 -0400 (EDT) Received: by mail-lf0-x243.google.com with SMTP id i3so3198254lfh.2 for ; Wed, 12 Apr 2017 06:44:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkQcdZFNaK+I1Mup8PlXevxnOkpeOYeHiQw3vDC0ggs=; b=qpyUzLYHrm9vbo06z+zHNI5FKc0XkKXflNOtKzBS6ANyzxh95W2xkvvjz4IyRwzhCo qgaY2Ic5nErYw7atlz/GQhNIYvRAuaveQyMi7hph94/ZRbIOv6N70glHS9c6fHfqRBgI oeixwpNipYCwaDwk/RMJzYu8SHqClvvMJLD2cmC/DJYawj2unJ6SIYhjB0j+/LnkzEOE RPOCs4eXlfE69f1wtmxVsbPxthXWq+LojD1ueBHCuHdznrtVLrR0keMiL8qhACk78/WG mpsxq3Si98zUoDLgKuZwH/gMBiwPz6c4MCxZlec4/7VpnXrfMszYuUynfwhzSCNJ6qI3 kpJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZkQcdZFNaK+I1Mup8PlXevxnOkpeOYeHiQw3vDC0ggs=; b=I+R7AA8ONBL5jdNDnw+UjLLkprkVOgMk1zWCFnxINfLCJh67gpm00ylNQ5Cp3cJ5Yl z3VohnonSRefOiB1ckPZCYSCtjsYKLFC+v/irPLsklEhH108LYpzLWj/C6hy+FcQNPkg jsQkxKyroZcesHgrJNoCdZi/kBe16mD5/7+7gHqNnxEVl+oAQ3DQMfBwqcdjy8wjrLgC G7pJ8H/whCz5PwTbnbIUAuTxQ/c5jtoODoTJ31/vUobuOr/bnmciQWCsf0lzfyv9TN2K tr3O/ccDpRNLG5BPkYEudUI2JDW+nHJcFqEqDYs+EawsvwtJlGgZkBeOmnwKRhWtzBpD 4oGA== X-Gm-Message-State: AFeK/H32Z8XgdOb83ERtNWmxfI6YAMSOVXRMt2y2rfBje0215oKUKFr3ABElS8VKHvZKmg== X-Received: by 10.25.76.194 with SMTP id z185mr21498153lfa.183.1492004666010; Wed, 12 Apr 2017 06:44:26 -0700 (PDT) Received: from [192.168.100.11] (37-219-194-68.nat.bb.dnainternet.fi. [37.219.194.68]) by smtp.gmail.com with ESMTPSA id e91sm4170562lji.40.2017.04.12.06.44.24 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 12 Apr 2017 06:44:25 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jonathan Morton In-Reply-To: Date: Wed, 12 Apr 2017 16:44:21 +0300 Cc: Kevin Darbyshire-Bryant , George Amanakis , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <228FEE75-471C-4F92-9176-62F8A8A71E9C@gmail.com> References: <1698783902.612018.1491919195146.ref@mail.yahoo.com> <1698783902.612018.1491919195146@mail.yahoo.com> <322beef3-fd84-144c-6718-795eff0e4435@darbyshire-bryant.me.uk> To: xnor X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Choosing a tin to work on 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: Wed, 12 Apr 2017 13:44:27 -0000 > On 12 Apr, 2017, at 15:48, xnor wrote: >=20 > Hey, >=20 >>> s64 tdiff =3D b->tin_time_next_packet - now; >>> if(tdiff <=3D 0 || tdiff <=3D best_time) { >>> best_time =3D tdiff; >>> best_tin =3D tin; >>> } >>=20 >> I'll try to answer this based on a vague bit of understanding...and = then Jonathan can shoot me down as well :-) >>=20 >> So the 'best_time' is signed because we can have a packet in a tin = that is not yet due to be sent (a positive result...ie. we have got here = early) and/or we can have a tin that is due now/overdue (a zero/negative = result, we've got here late) >>=20 >> The complication is that we can have multiple tins overdue, so we = want the highest priority *and* least overdue (least late) tin - this is = the reason for searching in tin_order[oi] and as a result tdiff can be = <=3D0 and bigger than best_time. >>=20 >> best_time is initialised to the 'most early' time possible. > that makes no sense to me. >=20 > best_time is initialized to some high value (though why is it not = 0x7FFF FFFF FFFF FFFFL, the highest possible positive s64?) such that no = matter how far tdiff is in the future, best_time will always be set to = the lower tdiff. > (Just like you would initialize a variable keeping track of the max to = the lowest possible value, you set a min variable to the highest = possible value.) >=20 > But if you wanted best_time to end up as the lowest value, then you = would have to only set it if tdiff < best_time (or <=3D if you actually = want to prefer the last tin if they happen to have the same tdiff), and = not also if tdiff <=3D 0. >=20 > For example, if tdiff values were 5000, -5000, 0 then best_time would = be set to 0. The last value less than or equal to zero will always win = as best_tin. > If all tdiff values are positive then best_time will end up as the = lowest value however. For some reason I never seem to have got the initial question post. The = two of you are broadly right though. The intention here is: - Find the highest-priority tin with a packet already due; - If none are due yet, find the one with a packet due soonest. This should have the same type of =E2=80=9Csoft priority=E2=80=9D = behaviour as the previous WRR version, but I was hoping it could reduce = the latency for processing sparse low-latency tins while under steady = bulk load. - Jonathan Morton