On 10.12.2011 19:35, John A. Sullivan III wrote: > On Sat, 2011-12-10 at 18:57 +0100, Michal Soltys wrote: <snip> So, > again, trying to wear the eminently practical hat of a sys admin, for > periodic traffic, i.e., protocols like VoiP and video that are sending > packets are regular intervals and thus likely to reset the curve after > each packet, m1 helps reduce latency while m2 is a way of reducing the > chance of overrunning the circuit under heavy load, i.e., where the > concave queue is backlogged. > Well, updated, - not "reset". The latter [kind of] implies the return to original form, and just so we're on the same page - the curve would have to be completely under the old one for that to happen. There's also no chance of overloading anything - except if a machine is shaping on behalf of something upstream with smaller uplink, and doing so without UL keeping LS in check. > When we start multiplexing streams of periodic traffic, we are still > fine as long as we are not backlogged. Once we are backlogged, we > drop down to the m2 curve which prevents us from overrunning the > circuit (assuming the sum of our rt m2 curves<= circuit size) and > hopefully still provides adequate latency. If we are badly > backlogged, we have a problem with which HFSC can't help us :) (and I > suppose where short queues are helpful). > Keep in mind that not backlogged classes are not hurt by backlogged ones. And you can't overrun - be it m1 or m2, or at which point any class activates (providing curves make sense). If everything is backlogged, you still get nicely multiplexed traffic as defined by your hierarchy. If anything briefly stops being backlogged, it will get bonus on next backlog period - while making sure, it wouldn't go with new curve above previous backlog period's one (and assuming its actual rate is not above the defined RT curve, as in such case it will get bonus from excess bandwidth available as specified by LS (or will get none, if LS is not defined)). > If you have a chance, could you look at the email I sent entitled "An > error in my HFSC sysadmin documentation". That's the last piece I > need to fall in place before I can share my documentation of this > week's research. Thanks - John Yes, will do. Btw, have you check the manpages of recent iproute2 w.r.t. hfsc ? Lots of this should be explained, or at least mentioned there. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html