netdev - Re: Latency guarantees in HFSC rt service curves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 10 Dec 2011 18:57:28 +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-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.
--
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