From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spostino.sms.unimo.it (spostino.sms.unimo.it [155.185.44.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B23FB21F0F0 for ; Fri, 9 Aug 2013 02:35:06 -0700 (PDT) Received: from [212.84.36.20] (port=50238 helo=[192.168.15.101]) by spostino.sms.unimo.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7j66-0004r1-Fd; Fri, 09 Aug 2013 11:35:03 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Paolo Valente In-Reply-To: <5204ACCE.50006@orange.com> Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130808084920.7ebc306d@nehalam.linuxnetplumber.net> <52048FF7.8040200@orange.com> <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> <5204ACCE.50006@orange.com> To: MUSCARIELLO Luca OLNC/OLN X-Mailer: Apple Mail (2.1283) UNIMORE-X-SA-Score: -2.9 X-Mailman-Approved-At: Sat, 24 Aug 2013 16:58:59 -0700 Cc: bloat Subject: Re: [Bloat] Fw: video about QFQ+ and DRR X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Fri, 09 Aug 2013 09:35:07 -0000 X-Original-Date: Fri, 9 Aug 2013 11:35:01 +0200 X-List-Received-Date: Fri, 09 Aug 2013 09:35:07 -0000 Il giorno 09/ago/2013, alle ore 10:48, MUSCARIELLO Luca OLNC/OLN ha = scritto: > Hi, >=20 > few questions in line. >=20 > Luca >=20 >=20 > On 08/09/2013 09:58 AM, Paolo Valente wrote: >> Il giorno 09/ago/2013, alle ore 08:45, MUSCARIELLO Luca OLNC/OLN ha = scritto: >>=20 >>> Hi, >>>=20 >>> nice demo. >>>=20 >> Thanks. >>=20 >>> While I am not surprised about the good performance of QFQ+, >>> I do not understand why DRR (I guess linux SFQ, i.e. per-flow = DRR+SQdrop) >>> works so bad. >>>=20 >>> If the two schedulers are serving the same kind of flow (IP 5-tuple) = the level >>> of protection to low rate (< fair rate) flows should be the same = (approx). >>>=20 >> That 'approx' plays a critical role for the bad results with DRR. In = particular, problems arise because of the following theoretical issue. >> Consider the packet service time for a flow, i.e., the time to = transmit one maximum-size packet of the flow at the rate reserved to the = flow. For each flow, the worst-case packet delay/jitter guaranteed by = QFQ+, with respect to packet completion times in an ideal, perfectly = fair system, is equal to a few times the packet service time for the = flow. In contrast, with DRR this delay/jitter is independent of the = packet service time, and grows linearly with the number of flows. >> Hence, the shorter the packet service time is, the higher this delay = becomes with respect to the packet service time. >>=20 >> In the In the test, >> 1) the total number of flows N is equal to 501, >> 2) the video-streaming server is reserved a bandwidth such that its = packet service time complies with the frame playback period, >> 3) the time to transmit 500 maximum-size packets at line rate is much = higher than the packet service for the video-streaming server, and = hence, of the frame period. >=20 > 1) AFAIK, sch_drr.c is class-based queuing and not per-flow queuing = (correct me if I am wrong). Certainly it is a classful queueing discipline. Just to sync with you, = what do you mean with per-flow as opposed to class-based? Do you mean that the scheduler internally and autonomously = differentiates packets into distinct flows according to some internal = classification rule (as it is the case for SFQ)? If so, then you are right. > So, when you say N =3D 501 flows, do you mean that in your demo you = configured class =3D flow (e.g. 5-tuple) > or you have multiple applications in the same class sharing a single = (class) queue? >=20 500 classes, one for each UDP flow, plus one class for the video stream. > 2) do you mean that the class "video" gets a weight (per-class weight, = with one single video flow in this case?) > such that, in average, it gets a weighted fair share large enough for = the video rate? >=20 Yes > 3) can you plug other qdiscs in QFQ+? If you mean creating a hierarchy in which some of the classes scheduled = by QFQ+ contain both a different queueing discipline and other classes = scheduled by that internal discipline, then yes. > Is QFQ+ a candidate to replace HTB (or DRR) in Linux?, Of course in my position I can answer such a question only in principle. = HTB does things that QFQ+ does not, such as rate limitation. In my demo = I used exactly HTB to limit the rate. Instead, as for DRR, its final goal perfectly matches that of QFQ+. = There are however scenarios where DRR is faster than QFQ+, and may even = provide a better delay/jitter. Basically, it happens when all = flows/classes have the same weight and the same packet length, i.e., = exactly in the cases where you do not need a more accurate fair-queueing = scheduler than DRR. > or maybe HTB is already outdated and sch_drr.c might replace = sch_htb.c in linux 3.7. >=20 >> As a consequence, when DRR incurs its physiological O(N) delay, the = playback buffer on the client side runs out of frames. >>=20 >>> Maybe Paolo said that in the talk and I might have missed something. >>> Is QFQ+ working on a different definition of flow than DRR?, >> No, on the same. > what is the definition of flow used or class? >=20 flow =3D class in the test Paolo -- Paolo Valente =20 Algogroup Dipartimento di Fisica, Informatica e Matematica =09 Via Campi, 213/B 41125 Modena - Italy =20 homepage: http://algogroup.unimore.it/people/paolo/