General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Paolo Valente <paolo.valente@unimore.it>
To: MUSCARIELLO Luca OLNC/OLN <luca.muscariello@orange.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Fw: video about QFQ+ and DRR
Date: Fri, 09 Aug 2013 07:59:05 -0000	[thread overview]
Message-ID: <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> (raw)
In-Reply-To: <52048FF7.8040200@orange.com>


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.

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?
> 
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
> 
> Luca
> 
> 
> 
> On 08/08/2013 06:09 PM, Luigi Rizzo wrote:
>> very nice and convincing demo.
>> 
>> good job paolo!
>> 
>> luigi
>> 
>> On Thu, Aug 8, 2013 at 5:49 PM, Stephen Hemminger <stephen@networkplumber.org> wrote:
>> Thought this might be interesting to this list.
>> ---
>> From: Paolo Valente
>> 
>> 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
>> 
>> 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.
>> 
>> Thanks,
>> Paolo
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
>> 
>> 
>> 
>> -- 
>> -----------------------------------------+-------------------------------
>>  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)
>> -----------------------------------------+-------------------------------
>> 
>> 
>> _______________________________________________
>> Bloat mailing list
>> 
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 


--
Paolo Valente                                                 
Algogroup
Dipartimento di Fisica, Informatica e Matematica		
Via Campi, 213/B
41125 Modena - Italy        				  
homepage:  http://algogroup.unimore.it/people/paolo/


  reply	other threads:[~2013-08-09  7:59 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08 15:49 Stephen Hemminger
2013-08-08 16:09 ` Luigi Rizzo
2013-08-09  6:45   ` MUSCARIELLO Luca OLNC/OLN
2013-08-09  7:59     ` Paolo Valente [this message]
2013-08-09  8:48       ` MUSCARIELLO Luca OLNC/OLN
2013-08-09  9:35         ` Paolo Valente
2013-08-09 11:02           ` MUSCARIELLO Luca OLNC/OLN
2013-08-09 11:30             ` Luigi Rizzo
2013-08-09 13:06               ` MUSCARIELLO Luca OLNC/OLN
2013-08-09 13:53                 ` Paolo Valente
2013-08-09 16:08                 ` Dave Taht
2013-08-12  8:28                   ` [Bloat] " Paolo Valente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it \
    --to=paolo.valente@unimore.it \
    --cc=bloat@lists.bufferbloat.net \
    --cc=luca.muscariello@orange.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox