Re: LLQ- help

And mind you :-). I was not the one who talked about flows. I talked
about different interfaces or classes in the same policies. Two flows
in the same queue coming from the same input interface be it 1 or 19
phones is still 1 input 1 output. To see the queueing, you need
multiple input interfaces. Think of a Y.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Mon, Dec 17, 2012 at 8:31 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
> Paul,
>
> If there was no congestion on the TX ring, there was no LLQ. TX ring
> congestion is what signals to IOS that software queueing needs to be
> engaged. Your test was flawed, sorry to say.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Mon, Dec 17, 2012 at 8:25 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>> I have tested it precisely!
>>
>> I put Voice traffic into the Priority Class and left the burst to default.
>>
>> I placed enough voice calls to equal the amount of traffic I used with the
>> "priority" command (4 calls at 32K each/NO VAD enabled). ALL traffic passed
>> and was not rejected. I placed a 5th call and it also went through with no
>> problem because it did not exceed the burst rate parameter (Voice is not
>> bursty). The second I placed another call, ALL of the Voice flows were
>> negatively impacted. The priority class began dropping traffic! It reacted
>> as if it was receiving burst traffic that exceeded what it would allow.
>>
>> When I extended the Burst parameter, ALL of the Voice call issues cleared
>> up.
>>
>> There was NO congestion on the transmit ring at ANY time during this test.
>>
>>
>> I also performed the same test with Live Video but the results were
>> devastating due to the extreme Bursty nature of the traffic I was using. I
>> needed to extend the  "BURST" parameter extensively due  to it's extreme
>> restrictive default.
>>
>> This is why some people misspeak and say that the Priority class is a
>> maximum value. It's true in that it binds the high end bandwidth but it does
>> ALLOW you to burst and squeeze a little bit more by default. It's just
>> REALLY restrictive. It does not enforce the 1 to 2 second recommendation.
>>
>> I still disagree with your example of where you " MAY SEE" queueing of
>> packets since I have NOT been able to prove it to this point. I did not ask
>> you to show me the packets to be confrontational or argumentative. I
>> actually thought I was going to learn something in this conversation about
>> how the Priority Queue actually buffers packets. I don't know what command
>> you used to verify this.
>>
>> This is why I am NOT confused about how LLQ works. I understood what the
>> BURST parameter actually does. I am NOT guessing.
>>
>> Policing will impose its constraint weather you are congested on the TX ring
>> or NOT. Same goes for Shaping!
>>
>> Paul
>>
>> Paul Negron
>> CCIE# 14856
>> negron.paul_at_gmail.com
>>
>>
>>
>> On Dec 17, 2012, at 10:19 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>>
>> On Mon, Dec 17, 2012 at 7:11 PM, Marko Milivojevic <markom_at_ipexpert.com>
>> wrote:
>>
>>
>> Yeah, I've seen that in the command reference as well. It's not
>> exactly well documented what it does.
>>
>>
>> What I suspect though (and this is purely speculation) is that it
>> allows the traffic to burst for the specified time when the LLQ is
>> engaged, which means when TX ring (or other choke point, i.e. shaper
>> in the parent class) trigger a congestion. Since there's no LLQ when
>> there's no congestion, I don't see how this parameter is at all
>> relevant when LLQ is not active. That's the thing with your statement
>> about 30 seconds that I mostly disagree with.
>>
>> --
>> Marko Milivojevic - CCIE #18427 (SP R&S)
>> Senior CCIE Instructor - IPexpert
Blogs and organic groups at http://www.ccie.net