From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by huchra.bufferbloat.net (Postfix) with ESMTP id 4C0372007D0 for ; Fri, 9 Aug 2013 01:48:17 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 658724102A5; Fri, 9 Aug 2013 10:48:16 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.orange.com (Postfix) with ESMTP id 67F5041028B; Fri, 9 Aug 2013 10:48:15 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Aug 2013 10:48:15 +0200 Received: from [10.193.161.45] ([10.193.161.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Aug 2013 10:48:14 +0200 Message-ID: <5204ACCE.50006@orange.com> Date: Fri, 09 Aug 2013 10:48:14 +0200 From: MUSCARIELLO Luca OLNC/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Paolo Valente References: <20130808084920.7ebc306d@nehalam.linuxnetplumber.net> <52048FF7.8040200@orange.com> <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> In-Reply-To: <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2013 08:48:14.0719 (UTC) FILETIME=[2F9350F0:01CE94DD] 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 Reply-To: MUSCARIELLO Luca OLNC/OLN List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 08:48:17 -0000 Hi, few questions in line. Luca 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: > >> Hi, >> >> nice demo. >> > 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. >> >> 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). >> > 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, > 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. 1) AFAIK, sch_drr.c is class-based queuing and not per-flow queuing (correct me if I am wrong). So, when you say N = 501 flows, do you mean that in your demo you configured class = flow (e.g. 5-tuple) or you have multiple applications in the same class sharing a single (class) queue? 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? 3) can you plug other qdiscs in QFQ+? Is QFQ+ a candidate to replace HTB (or DRR) in Linux?, or maybe HTB is already outdated and sch_drr.c might replace sch_htb.c in linux 3.7. > 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. what is the definition of flow used or class?