Re: 3560 Policer Burst Value

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>> 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