Re: 3560 Policer Burst Value (rewritten in bps)

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