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?
_______________________________________________
Bloat mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/bloat
