John A. Sullivan III wrote:
One thing that I recall from when hfsc first came out is that when
testing it wouldn't limit bulk if the class wasn't backlogged.
For most people if you have enough bandwidth I doubt this is an issue,
but at the time I was limiting for a 256kit dsl line with five users.
I haven't played around with it enough in the lab yet so I'm going
strictly on the theory. I believe the class should backlog as soon as
there is a packet in queue. An environment where bandwidth is so
constrained sounds like an ideal place to have separate rt and ls
curves.
Yea, I believe I did - but then it was a longtime ago. I think the issue
was that an empty the class would dequeue instantly but the transmission
time of that now gone packet didn't seem to affect other empty classes
also receiving a packet. It would probably have only affected further
packets to the same class.
I did raise it at the time and IIRC the author said that he would have
to make hfsc even more non work conserving to deal with this case.
My test was a bit contrived I guess.
The rt curve would allocate and guarantee a small amount of bandwidth to
each queue. If some of those classes have time sensitive traffic, you
could define a dilinear rt curve which would help jump those packets in
front of the others. Then, with the ls curves, you could allocate spare
bandwidth.
I'll have to dig out my old tests - I guess I did try to do this - but
may have failed :-)
Of course, with five full queues firing
full sized packets at 256kbit one can expect almost 250ms latency and
can only guarantee 50 kbits.
I recall that I did manage to set things up so my rt was not delayed by
more than one bulk packet in the bulks backlogged test.
Good luck - John
Thanks - I'll need it :-)
Andy.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
