From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp26.sms.unimo.it (smtp26.sms.unimo.it [155.185.44.26]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 74C9B201253 for ; Fri, 9 Aug 2013 00:59:03 -0700 (PDT) Received: from [212.84.36.20] (port=49708 helo=[192.168.15.101]) by smtp26.sms.unimo.it with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1V7hb8-0001Dc-1T; Fri, 09 Aug 2013 09:58:59 +0200 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Paolo Valente In-Reply-To: <52048FF7.8040200@orange.com> Content-Transfer-Encoding: quoted-printable Message-Id: <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> References: <20130808084920.7ebc306d@nehalam.linuxnetplumber.net> <52048FF7.8040200@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 07:59:05 -0000 X-Original-Date: Fri, 9 Aug 2013 09:58:56 +0200 X-List-Received-Date: Fri, 09 Aug 2013 07:59:05 -0000 Il giorno 09/ago/2013, alle ore 08:45, MUSCARIELLO Luca OLNC/OLN ha = scritto: > Hi, >=20 > nice demo. >=20 Thanks. > 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. In the In the test,=20 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. As a consequence, when DRR incurs its physiological O(N) delay, the = playback buffer on the client side runs out of frames. > 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. > and is DRR Linux SFQ? >=20 No, it is just DRR (sch_drr.c). I hope I was not too confusing, and I am willing to answer any further = question, Paolo >=20 > Luca >=20 >=20 >=20 > On 08/08/2013 06:09 PM, Luigi Rizzo wrote: >> very nice and convincing demo. >>=20 >> good job paolo! >>=20 >> luigi >>=20 >> On Thu, Aug 8, 2013 at 5:49 PM, Stephen Hemminger = wrote: >> Thought this might be interesting to this list. >> --- >> From: Paolo Valente >>=20 >> Hi, >> I just uploaded the following 7-minute video showing the QoS and the = execution time of QFQ+, compared to those of DRR: >> http://youtu.be/bG2ACt4na7A >>=20 >> I would like to advertise this video. If I may ask for your help, do = you think that linux-kernel, linux-net or linux-netdev may be = appropriate? >> Any other suggestion is more than welcome. >>=20 >> Thanks, >> Paolo >>=20 >> _______________________________________________ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >>=20 >>=20 >>=20 >> --=20 >> = -----------------------------------------+------------------------------- >> Prof. Luigi RIZZO, rizzo@iet.unipi.it . Dip. di Ing. = dell'Informazione >> http://www.iet.unipi.it/~luigi/ . Universita` di Pisa >> TEL +39-050-2211611 . via Diotisalvi 2 >> Mobile +39-338-6809875 . 56122 PISA (Italy) >> = -----------------------------------------+------------------------------- >>=20 >>=20 >> _______________________________________________ >> Bloat mailing list >>=20 >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >=20 -- 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/