Re: LLQ- help (with elephants)

Well, I tried a 12.4(15)T and I get your output:

RouterA#sh policy-map int
  Serial0/0/0

   Service-policy output: tst

     Class-map: ef (match-all)
       0 packets, 0 bytes
       5 minute offered rate 0 bps, drop rate 0 bps
       Match: precedence 5
       Queueing
         Strict Priority
         Output Queue: Conversation 40
         Bandwidth 30 (%)
         Bandwidth 30 (kbps) Burst 750 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

which leds me to believe that this is pre HQF ( 12.4(20)T ) behaviour.
-Carlos

Carlos G Mendioroz @ 20/12/2012 09:14 -0300 dixit:
> Narbik,
> Would you mind sharing which IOS version those tests were made on ?
> Trying to reproduce it and I get burst at 1500 instead of your 750 value
> on the serial interface with the tst policy.
> Also, I'm curious about your show policy map showing "conversations"
> wich is a gadget from CBWFQ which is not present on HQF.
> On 15.1(1)T :
>
> HQ-1#sh run int s 0/1/1
> Building configuration...
>
> Current configuration : 204 bytes
> !
> interface Serial0/1/1
> bandwidth 100
> ip address 10.1.7.101 255.255.255.0
> ip access-group drop in
> loopback
> no keepalive
> clock rate 2000000
> max-reserved-bandwidth 80
> service-policy output tst
> end
> HQ-1#sh policy-map int
> Serial0/1/1
>
> Service-policy output: tst
>
> queue stats for all priority classes:
>
> queue limit 64 packets
> (queue depth/total drops/no-buffer drops) 0/0/0
> (pkts output/bytes output) 0/0
>
> Class-map: ef (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: precedence 5
> Priority: 30% (30 kbps), burst bytes 1500, b/w exceed drops: 0
>
>
> ...
>
> For sake of comparizon, your R1 output:
> R1#Show policy-map interface
> Serial0/1
> Service-policy output: tst
> Class-map: ef (match-all)
> 0 packets, 0 bytes
> 5 minute offered rate 0 bps, drop rate 0 bps
> Match: precedence 5
> Queueing
> Strict Priority
> Output Queue: Conversation 40
> Bandwidth 30 (%)
> Bandwidth 30 (kbps) Burst 750 (Bytes)
> (pkts matched/bytes matched) 0/0
> (total drops/bytes drops) 0/0
>
> Tks,
> -Carlos
>
> P.S.
> Why on earth trying to understand this stuff is childish ?
>
> Narbik Kocharians @ 19/12/2012 21:18 -0300 dixit:
>> To all,
>>
>>
>> Please go to micronics.nl and download the LLQ-LAB and I think I have
>> done
>> my best to show how the "burst" in LLQ works just like the Bc in single
>> rate two color marker, by the way there are no Be in two color marker
>> with
>> single rate. BUT I do not have time to go over that and prove it, even
>> though I can.
>>
>>
>> BTW, this is my last post, i am conducting a class and have no time for
>> this kind of childish stuff , It is embarrassing (Double
>> dare??)sharing which
>> wow.........
>>
>> Have fun.
>>
>>
>> On Wed, Dec 19, 2012 at 4:01 PM, Marko Milivojevic
>> <markom_at_ipexpert.com>wrote:
>>
>>> On Wed, Dec 19, 2012 at 3:43 PM, Paul Negron <negron.paul_at_gmail.com>
>>> wrote:
>>>> Therefore, when I placed 4 calls that tootled approx 112K of the Pipe.
>>> All
>>>> worked well. The 5th call went through fine cause it was not enough to
>>>> congest the link. The 6th call had to have had congested the link which
>>>> kicked in the BURST parameter set in the Priority Queue and traffic
>>> dropped
>>>> traffic out of the VOICE CLASS.
>>>>
>>> [...]
>>>> I also have in my notes that the POLICE action worked very similar to a
>>> Single Rate 2 Color Policer. '
>>>>
>>>> The conclusion was that the Priority Class Burst Parameter will drop
>>> traffic only when the link is congested, even if it's by a little
>>> depending
>>> on the traffic.
>>>
>>> Dear Lord, I don't even know where to begin with this...
>>>
>>> #1 You are aware that 5th call may have gone through because the
>>> timing on it was such that packets were arriving in such a way to
>>> never trigger a congestion, even though you exceeded the bandwidth by
>>> calculation, but not in reality? See example from Carlos about
>>> elephants (brilliant!)
>>>
>>> #6 6th call of course overwhelmed the link, as the statistical timing
>>> offset was astronomical at that point for different flows to
>>> interleave without triggering the congestion. When this happens, *of
>>> course* policer kicks in and all traffic, regardless of the flow gets
>>> policed at the specified rate.
>>>
>>> #3 "Kicked out of VOICE CLASS" - how *on Earth* does traffic gets
>>> kicked out of the class once it's classified there?
>>>
>>> #4 Higher burst parameter causes more draps? What's this about? If
>>> anything, higher burst means longer measurement interval (in what you
>>> claim it does), or higher calculated rate that can exceed without
>>> causing drops. Are you now claiming that BURST parameter in the
>>> priority command does something entirely different? If yes, pray
>>> explain, as I have lost you completely at this point.
>>>
>>> Last but not the least...
>>>
>>>>
>>>> This is how the BURST parameter works.
>>>
>>> HOW? I never saw an explanation, just a mass confusion as some
>>> authority-referencing (Wendell), which is not a valid argument.
>>>
>>> --
>>> Marko Milivojevic - CCIE #18427 (SP R&S)
>>>
>>
>>
>>
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net