From: Michal Soltys <soltys@ziu.info>
To: "John A. Sullivan III" <jsullivan@opensourcedevel.com>
Cc: netdev@vger.kernel.org
Subject: Re: Latency guarantees in HFSC rt service curves
Date: Sat, 10 Dec 2011 18:57:28 +0100 [thread overview]
Message-ID: <4EE39D88.9010002@ziu.info> (raw)
In-Reply-To: <1323531352.3159.106.camel@denise.theartistscloset.com>
On 11-12-10 16:35, John A. Sullivan III wrote:
> Makes perfect sense but seems to confirm what I was thinking. There
> seems to be little practical use for the m1 curve. Assuming the
> queues are often backlogged (or we would not be using traffic
> shaping), m1 only applies for a typically very short period of time,
> perhaps one packet, after that, the latency is determined exclusively
> by m2. So, unless I've missed something (which is not unlikely), m1
> is very interesting in theory but not very useful in the real world.
> Am I missing something?
You forgot about how curves get updated on fresh backlog periods.
If your important traffic designated to some leaf is not permanently
backlogged, it will be constantly switching between active/inactive
states. Any switch to active state will update its curves (minimum of
previous one vs. fresh one anchored at current (time,service)), during
which it will regain some/all of the m1 time.
For simplicity, say you have uplink 10mbit, divided into two chunks
chunks (A and B) with convex/concave curves. On A there's 24/7 torrent
daemon, on B there's some low bandwidth latency sensitive voip/game/etc.
The B will send 1 packet, maybe a few and go inactive - possibly for
tens/hundreds of miliseconds. Next time the class becomes backlogged,
the curves will be updated, and almost for sure the whole new one will
be chosen as the minimum one - and m1 will be used. In a sort of way -
m1 will be (for the most part) responsible for "activation"
latency-sensitive bandwidth, and m2 will be more responsbile for the
bursts. Difference between m1 and m2 and 'd' duration of m1 will skew
the role.
Perhaps easier example: setup as above, but put a ping on B with 100ms
delay between sends. Every single one of those will go at m1 speed
(crazy curve setups aside).
Similary, if you consider A's RT set to say 5mbit, and B to 4mbit/2mbit
(and LS fifty/fifty). And some video in B now, that doesn't push itself
more than 2mbit. Each packet of B will use m1.
next prev parent reply other threads:[~2011-12-10 17:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-09 21:51 Latency guarantees in HFSC rt service curves John A. Sullivan III
2011-12-10 13:03 ` Michal Soltys
2011-12-10 15:35 ` John A. Sullivan III
2011-12-10 17:57 ` Michal Soltys [this message]
2011-12-10 18:35 ` John A. Sullivan III
2011-12-13 23:46 ` Michal Soltys
2011-12-14 5:16 ` John A. Sullivan III
2011-12-14 5:24 ` John A. Sullivan III
2011-12-15 1:48 ` Michal Soltys
2011-12-15 7:38 ` John A. Sullivan III
2011-12-17 18:40 ` Michal Soltys
2011-12-17 20:41 ` John A. Sullivan III
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EE39D88.9010002@ziu.info \
--to=soltys@ziu.info \
--cc=jsullivan@opensourcedevel.com \
--cc=netdev@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).