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 way..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 rateright?
>>
>> " 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
>> bandwidth.that the priority Q can use as much it wanted. I am even
debating
>> that the priority Q is a QUEUE at all!!!!
>>
>> so now 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
Received on Mon Dec 17 2012 - 21:35:44 ART
This archive was generated by hypermail 2.2.0 : Tue Jan 01 2013 - 09:36:53 ART