From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (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 D183E21F1A9 for ; Thu, 5 Dec 2013 12:07:23 -0800 (PST) Received: by mail-la0-f43.google.com with SMTP id n7so10438827lam.2 for ; Thu, 05 Dec 2013 12:07:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nyEqghwVYWGUr1gaYn6XE/mEFBcgfIL8DfSPfmLodxQ=; b=yRQ75MJFuzRpjx7YTa6cYEvsgXStxp+ThJP6wmBoB3BAPlEbMzvY42KVm6vf3fxx4X jmmPQpjxsSwm4jPftRsnZ6xS/5dKBT5z0Lv3r8ZkDNst6ksDqfUPqYTT+qDxPsS11csX yyxPzYiiuLNykDA7BWVkHHpwnokJj++nmHXb6OJUnUmFCif8rNcXxeU85QvYtHJkmRgA JM/4hNl2OrZDVkIwecyk/YhPRPFxEqOvRJLCvG/MEaRgOtS9bi5QOyNskRT6aUaUo83Z QZyJriOPUdhRRPsDNVI3njFUXx9/I11ud1WeuCpfWCasDjHmHLWKiu72B063om6e4jj+ PANA== X-Received: by 10.112.170.200 with SMTP id ao8mr352118lbc.41.1386274041192; Thu, 05 Dec 2013 12:07:21 -0800 (PST) Received: from [10.241.252.115] (37-136-3-220.nat.bb.dnainternet.fi. [37.136.3.220]) by mx.google.com with ESMTPSA id mx3sm10683622lbc.14.2013.12.05.12.07.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Dec 2013 12:07:20 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Jonathan Morton In-Reply-To: Date: Thu, 5 Dec 2013 22:06:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <269B8D3A-09C7-411E-9482-27CAA898A29F@gmail.com> References: To: Dong Mo X-Mailer: Apple Mail (2.1085) Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] New to codel-- how to run codel on a linux box? 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: Thu, 05 Dec 2013 20:07:24 -0000 On 5 Dec, 2013, at 9:49 pm, Dong Mo wrote: > And sending packet from the sender, where qdisc is set, to the = receiver, the queuing delay is quite small and is approximately the same = as when fq_codel enabled. >=20 > However, if I am not using sfq, and send only one flow over this link, = the delay will explode again. >=20 > So is sfq here cut off the queue length somehow? How should I make a = bufferbloat fair queue on linux box using tc qdisc? How are you measuring the delay? Ping? This is relevant because ICMP (ping) occupies a different "flow" than = the TCP stream(s) you are loading the link with. SFQ and fq_codel both = service flows fairly, ensuring that each gets some traffic through = continuously. So your pings have low latency even if SFQ's queue is = full. The difference is that fq_codel keeps the queue of each flow short, = while SFQ allows each queue to grow up to the limit. The latter = behaviour is adequate in some situations, but has some bad consequences = such as slow recovery from packet loss on each flow. And because SFQ = can *only* keep the queue within limits by dropping packets, there = *will* be packet loss on a regular basis unless the receive window of = the TCP flow is exhausted first. By contrast fq_codel is ECN-aware, so = on ECN-enabled flows it can avoid dropping packets altogether while = still keeping latency low enough for rapid recovery if packet loss = occurs anyway. It also often happens that packets dropped due to a full queue happen to = be at the end of a TCP connection, for which detection and recovery of = the problem is much slower (and usually on very human-visible = timescales) than in the middle of a connection. In this case SFQ is no = help, because it also drops from teh tail of the queue, where the last = packets of a connection arrive. By contrast fq_codel drops from the = head of the queue when required (ie. when ECN is not available), so = unless two connections share a flow (rare but not impossible), the lost = packet will always be from the middle of a connection and will be = retransmitted quickly. That is the sort of behaviour you should test for when comparing = fq_codel and SFQ. A simple ping test under load is satisfied by both = qdiscs. - Jonathan Morton