Re: LLQ- help

I do disagree with most of it. Alas, I no longer have Spirent
SmartBits available to me to repost the detailed test I've done in the
past. Asking me to "show you packets" in the queue is a little bit
silly... ;-) I will give you two situations when you may see packets
in the queue...

To see the queueing in the LLQ you need to try more that one input
interface of the same speed (or greater, but then you will hit the
policer) as the outgoing. You will have packets in that queue, that
are indeed queued and sent.Another possibility is to have multiple
classes within the same policy configured for LLQ, which in turn will
create a single queue that may contain packets that are being actively
dequeued.

However, what you will *not* have with the LLQ is the packets queued
in this queue while other queues are being processed. In that sense, I
see how it can be confusing to think of LLQ as a meter and not a
queue.

Btw. that "burst" parameter is funny. I wonder what it actually does.

--
Marko Milivojevic - CCIE #18427 (SP R&S)
Senior CCIE Instructor - IPexpert
On Mon, Dec 17, 2012 at 6:35 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
> I would submit that the Priority Q is a Meter. Nothing more. Your comment of
> " Its almost always empty" is not true until you can show me ONE example
> where it has ever Queued traffic in the first place. Last time I checked
> there was no Memory buffer used to stage that traffic for that class. I
> personally have ONLY seen it drop traffic. I agree with Narbik. You CANNOT
> adjust the Q depth.
>
> If the TX ring has NO congestion the Priority Q can STILL drop traffic. The
> BURST has EVERYTHING to do with this!
>
> This means that the CBWFQ may not be doing its thing (bypassed) but the
> Priority Q is. It will not take as much as it wants. Do you disagree with
> this statement?
>
> We can take this offline if you would like. :-)
>
> By the wayb&..I  never said LLQ was Priority Queuing.
>
> Paul Negron
> CCIE# 14856
> negron.paul_at_gmail.com
>
>
>
> On Dec 17, 2012, at 9:13 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>
> Well, no. LLQ is decidedly not the same as the Priority Queue. It's a
> conditionally policed near-realtime queue, but that's about the only
> similarity it has with the priority queue.
>
> When TX ring signals no congestion, there's no LLQ, hence the whole
> 30-seconds only thing is hard to digest, if you indeed meant LLQ in
> your earlier message. Furthermore, what does burst have anything to do
> with this? :-)
>
> Now the idea it's not a queue at all is interesting one. I suppose you
> could think of it that way, but I'm afraid it's still a queue. Same
> way the priority lane for 1st class passengers is a queue, yet it's
> almost always empty because packets are processed first.
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Mon, Dec 17, 2012 at 6:01 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>
> ???????
>
> LLQ has a so called" Priority Q"   right?
>
> There is a  default burst rateb&right?
>
> " The default burst value, which is computed as 200 milliseconds of traffic
> at the configured bandwidth rate, is used when the burst argument is NOT
> specified. The range of the burst is from 32 to 2000000 bytes."
>
> I am disagreeing with the point that if the other classes are not using the
> bandwidthb&.that the priority Q can use as much it wanted. I am even debating
> that the priority Q is a QUEUE at all!!!!
>
> so nowb& WHat do you mean by , How does this relate to LLQ?
>
> Not argumentative! You got me curious about your comment/question.
>
> Paul
>
> Paul Negron
> CCIE# 14856
> negron.paul_at_gmail.com
> 303-725-8162
>
>
>
> On Dec 17, 2012, at 8:43 PM, Marko Milivojevic <markom_at_ipexpert.com> wrote:
>
> How does this relate to LLQ? :-)
>
> --
> Marko Milivojevic - CCIE #18427 (SP R&S)
> Senior CCIE Instructor - IPexpert
>
> On Mon, Dec 17, 2012 at 5:35 PM, Paul Negron <negron.paul_at_gmail.com> wrote:
>
> It depends on what code you are talking about. The Priority Q used to
> default
> to 30 ms burst rate which would allow to ONLY burst to 30 ms of traffic
> above
> the Priority rate. It's really not a Queue. I tested this with real Voice
> and
> Video  traffic a while back and it limited the calls/traffic with NO other
> traffic being used by other classes. The default policer in the Priority Q
> would default to a very very low burst rate and drop traffic even when the
> pipe was not filled.
>
>
> Paul Negron
> CCIE# 14856
> negron.paul_at_gmail.com
>
>
>
> On Dec 17, 2012, at 9:15 AM, dia.aliou_at_gmail.com wrote:
>
> As Carlos said, with only "priority percent 10", 10 percent of the
> bandwidth is reserved for this class, however if there is available
> bandwidth and the there is no congestion this class could use more than
> 10%. To enforce the reserved bandwidth to 10% you need to explicitly police
> the traffic.
>
>
> On 16 December 2012 13:26, Carlos G Mendioroz <tron_at_huapi.ba.ar> wrote:
>
> Janesh,
> implicit policing by the "priority" QPF command is done only when
> congestion is present and queueing control "engaged".
>
> If you want to restrict the stream at all times, explicit policing with
> "police" is needed.
>
> -Carlos
>
> janesh gs @ 16/12/2012 09:55 -0300 dixit:
>
> Hello there,
>
>
> Could someone please  explain the pros/cons of the following 2
> configuration options in a single policy-map scenario.
> Also where we will use one over the other in real life
>
> Option 1
> --------------
> policy-map BLAH
> class BLAH
> priority percent 10
> police cir percent 10
>
>
> Option 2
> --------------
> policy-map BLAH
> class BLAH
> priority percent 10
>
> All along I have been  sticking to Option 2.
>
> Many thanks,
> Janesh
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________**______________________________**
> ___________
> Subscription information may be found at:
>
> http://www.groupstudy.com/**list/CCIELab.html<http://www.groupstudy.com/list/
> CCIELab.html>
>
>
>
>
>
>
>
>
>
> --
> Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> ______________________________**______________________________**
> ___________
> Subscription information may be found at: http://www.groupstudy.com/**
> list/CCIELab.html <http://www.groupstudy.com/list/CCIELab.html>
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
>
> Blogs and organic groups at http://www.ccie.net
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
Blogs and organic groups at http://www.ccie.net