Re: 3560 Policer Burst Value

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>
> <mailto: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 <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>
>
>
>
>
>
>
>
>
>
>
> --
> *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
>

-- 
Carlos G Mendioroz  <tron_at_huapi.ba.ar>  LW7 EQI  Argentina
Blogs and organic groups at http://www.ccie.net