Re: 3560 Policer Burst Value

I do understand that caps have a meaning, but this is what Joe wrote:

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

and i have never hear the police rate in Bytes before.

On Fri, Sep 16, 2011 at 11:43 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar>wrote:

> Well, if my number had been 3Mbps, yes, but I was thinking bytes
> and that was the reason for the 3MBps. Caps do have meaning after all.
>
> I did change the units Joe used, though. Sorry if that caused some
> confusion.
>
> -Carlos
>
>
> Narbik Kocharians @ 16/09/2011 15:23 -0300 dixit:
>
>> Carlos,
>>
>> Shouldn't you divide 3000,000 by 8 or multiply 1500 by 8 before you do the
>> division?
>>
>> On Fri, Sep 16, 2011 at 10:37 AM, Carlos G Mendioroz <tron_at_huapi.ba.ar<mailto:
>> 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 = 2000 pps, or every .0005s.
>> Then, if even spaced, t - t1 * policed rate yields 1500 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>
>> >
>> <mailto: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 <mailto: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>
>> <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/<http://www.micronicstraining.com/>
>> >
>>
>> Sr. Technical Instructor
>> YES! We take Cisco Learning Credits!
>> Training & Remote Racks available
>>
>>
> --
> Carlos G Mendioroz <tron_at_huapi.ba.ar> LW7 EQI Argentina
>

-- 
*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
Blogs and organic groups at http://www.ccie.net