Message-ID: <4EE358A4.7060302@ziu.info>
Date:	Sat, 10 Dec 2011 14:03:32 +0100
From:	Michal Soltys <soltys@....info>
To:	"John A. Sullivan III" <jsullivan@...nsourcedevel.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Latency guarantees in HFSC rt service curves

On 11-12-09 22:51, John A. Sullivan III wrote:
> 
> Let's work through the math to make that more understandable. HFSC is
> committed to deliver 2 Mbps to video and each packet is 8KB long.
> Thus, HFSC's commitment to deliver that packet is within (8000 *
> 8)bits / 2,000,000(b/s) = 32ms.  I'm not quite sure why I come up with
> 32 and they say 33 but we'll use 33.  In other words, to meet the
> deadline based solely upon the rate, the bandwidth part of the rt
> service curve, the packet needs to be finished dequeueing at 33ms.
> Since it only takes 6.5ms to send the packet, HFSC can sit on the
> packet it received for 33 - 6.5 = 26.5ms.  This adds unnecessary
> latency to the video stream.

For the record, HFSC will only sit on anything if respective classes
(subtrees) are limited by UL. And RT curves ignore those. If you have
one leaf active, then it will just dequeue asap (modulo UL). If you
have more, then RT and afterwards LS will arbitrate the packets
w.r.t. to the curves you set (and if applicable - UL will stall LS
to match specified speeds).

> That's our documentation so I think I get it but here's my problem.
> Practically speaking, as long as it's not extreme, latency at the
> beginning of a video stream (I'm using video because that is the
> example given) is not an issue. 

> The problem is if I introduce latency in the video stream once it has
> started.  So what is the advantage of starting the stream in 3.5ms
> versus 26.5ms?

> The subsequent packets where latency really matters are all governed
> by the m2 curve at 2 Mbps in this example.

That 2mbit is worst-case scenario (congested link). Remember
about LS which will govern the remaining bandwidth as soon as all RT
requirements are fulfilled.

If you do need a bigger /guarantee/ no matter what, you need steeper m2.
Or different approach. HFSC won't give more that it's asked to do for -
if the RT curve's m2 is set to 2mbit, then packets enqueued in the leaf
with such curve will get 2mbit (modulo cpu/network/uplink
capability/etc.).

> Moreover, let's say I have three video streams which start
> simultaneously.  Only the first packet of the first stream receives
> the 6.6Mbps bandwidth guarantee of the first 10ms so the other videos
> receive no practical benefit whatsoever from this m1 curve.

If you want guarantees per flow, you have to setup for that (same
applies to other classful qdiscs). Rough simplistic scheme would be:

For N flows, you need N classes (+ appropriate filter setup to direct
them to respective leafs) - or - more elaborate qdisc at the leaf that
will go over packets (by quantity or their length) in e.g. round robin
fashion from different flows it can distinguish (and longer period of m1
that will be sufficient to cover more packets). Or something in between.

You have lots of tools to choose from (not all listed of course) -
fliters such as fw, u32, flow; qdiscs (meant to attach to leaf classes)
such as choke, red, sfq, drr; iptables targets (mark, classify). And
more.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists