Re: 3560 Policer Burst Value (rewritten in bps)

I think the police command on this particular platform is fairly insane.
Really Cisco? We are supposed to have to guess or trial by error what the
buffer should be (bc) in order for the hardware to sustain a particular
policed rate?

We should be putting in a policed rate CIR and the equipment should come up
with a reasonable burst value that works well in general given that CIR.
Sort of how it works on an IOS based router...you don't HAVE to specify
burst, it figures it out for you and you have the option to tweak it.

Am I the only one that finds this particular concept fairly insane?

On Fri, Sep 16, 2011 at 3:10 PM, Narbik Kocharians <narbikk_at_gmail.com>wrote:

> hahahaha
> Unbelievable!!!!!!!!!!!!!!!!!!!!!!!!!!
>
> On Fri, Sep 16, 2011 at 11:57 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:
>
>> Joe,
>> I think that your initial settings call for the policer to kick in
>> really fast, after all, you are policing @3Mb and sending @100Mb!
>>
>> The idea of the policer is that if 3Mbps are ok, then 1500 byte packets
>> should arrive @ 3000000/1500*8 = 250 pps, or every .004s.
>> Then, if even spaced, t - t1 * policed rate yields 1500 bytes and all
>> is good.
>>
>> If your source is CBR, all that makes the burst size important is jitter
>> (IPDV in Pavel referred document). Video is a whole different story, as
>> it is not CBR, but VBR. (Constant Bit Rate, Variable Bit Rate).
>> VBR codecs tend to have different design behaviours. An altogether
>> different problem.
>>
>> -Carlos
>>
>> Joe Astorino @ 16/09/2011 13:49 -0300 dixit:
>>
>>> PS I know these numbers are WAY off, but at least I think it makes the
>>> concept of how the burst works make more sense, at least for me. I think in
>>> the real world, there are many many other factors like the video codec being
>>> used, number of bytes in the payload of each packet, number of packets per
>>> second, etc.
>>>
>>> On Fri, Sep 16, 2011 at 11:44 AM, Joe Astorino <
>>> joeastorino1982_at_gmail.com <mailto:joeastorino1982_at_gmail.**com<joeastorino1982_at_gmail.com>>>
>>> wrote:
>>>
>>>
>>> OK, I have worked this out, at least in my own head to make sense.
>>> I thought I would share with you guys. A lot of this is based on
>>> assumptions, but at least it makes sense to me:
>>>
>>> Here is how I see things playing out with an 8000 byte burst size
>>>
>>> Assumptions:
>>> Interface is connected at 100Mbps
>>> Policed rate is 3Mbps
>>> Burst Size is set to 8000 Bytes
>>> Ethernet frame size is a maximum 1500 bytes
>>>
>>> By this logic, if the host is connected and sending at 100Mbps, and
>>> he is sending 100,000,000 bits per second or 12,500,000 bytes per
>>> second. If each frame is 1500 bytes, it is sending 12,500,000 /
>>> 1500 or about 8333 frames per second. That means every 1/8333
>>> seconds or .00012 seconds a 1500 byte frame arrives at the switch
>>> port and is evaluated against by policer.
>>> When the policer sees the frame, it first adds tokens to the bucket
>>> based on the formula (t1 - t) * policed rate where t1 is the packet
>>> arrival time and t is the last packet arrival time. This is in
>>> bytes so... every .00012 seconds a frame arrives and the policer
>>> puts 45 bytes into the bucket (3,000,000/8 * .00012). Obviously,
>>> this is a very low number and I think explains why the 8000 byte
>>> limit couldn't handle the bitrate
>>>
>>> After not too many intervals of 1500 byte frames coming in at .00012
>>> seconds, the BC bucket would be empty. Now...lets run the math with
>>> the BC size I have chosen, 37,500 bytes. All the other assumptions
>>> are the same here. BC_Size is the size of BC at the beginning of
>>> the interval
>>>
>>> Time: 0
>>> BC_Size: 37,500
>>>
>>> send the 1500 byte frame, leaving BC at 36,000 bytes
>>>
>>> Time: .00012 seconds
>>> BC_Size: 36,000 bytes
>>>
>>> add 45 bytes to the bucket, send the 1500 byte frame leaving BC at
>>> 34,545 bytes
>>>
>>> Time: .00024 seconds
>>> BC_Size: 34,545 bytes
>>>
>>> add 45 bytes to the bucket, send the 1500 byte frame leaving BC at
>>> 33,090 bytes
>>>
>>> Time: .00036 seconds
>>> BC_Size: 33,090 bytes
>>>
>>> add 45 bytes to the bucket, send the 1500 byte frame leaving BC at
>>> 31,635
>>>
>>> ...
>>>
>>> Now, with that math the rate can be sustained for about 28 intervals
>>> until the bucket is emptied and packets would start being dropped.
>>> So...that still doesn't really work because 28 intervals only takes
>>> us until .003 seconds until the bucket would be flattened. But then
>>> again, my assumptions could be way off. Everything is based on the
>>> idea that the unit is sending at the negotiated speed of 100Mbps and
>>> that is is constantly sending a stream of fixed length 1500 byte
>>> packets. That could be WAY off, but at least now having really
>>> thought through it, I think I have a better understanding.
>>>
>>> If anybody here knowledgeable on the subject happens to read this
>>> and think I'm off my rocker, please enlighten me I'd love to
>>> understand deeper.
>>>
>>> - Joe
>>>
>>> -- Regards,
>>>
>>> Joe Astorino
>>> CCIE #24347
>>> Blog: http://astorinonetworks.com
>>>
>>> "He not busy being born is busy dying" - Dylan
>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Joe Astorino
>>> CCIE #24347
>>> Blog: http://astorinonetworks.com
>>>
>>> "He not busy being born is busy dying" - Dylan
>>>
>>>
>> --
>> 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>
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> *Narbik Kocharians
> *CCSI#30832, CCIE# 12410 (R&S, SP, Security)
> *www.MicronicsTraining.com* <http://www.micronicstraining.com/>
> Sr. Technical Instructor
> YES! We take Cisco Learning Credits!
> Training & Remote Racks available
>
>

-- 
Regards,
Joe Astorino
CCIE #24347
Blog: http://astorinonetworks.com
"He not busy being born is busy dying" - Dylan
Blogs and organic groups at http://www.ccie.net