Re: 3560 Policer Burst Value

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