Re: prio + policing filter on ingress?

[Andy Furniss <andyqos@ukfsn.org>]

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.