Re: LLQ- help (with elephants)

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