From: Petr Lapukhov (petr@internetworkexpert.com)
Date: Thu Nov 23 2006 - 13:28:52 ART
Sorry for rude math here, Alexei corretly pointed me out that
128000/8 = 16000 bytes :)
Must be that stupid flu i caught a day ago :( Hope it won't persist for too
long ;)
2006/11/23, Petr Lapukhov <petr@internetworkexpert.com>:
>
> Chris Lewis spent many hours, trying to explain how shaping and policing
> differ,
> and why there is no Tc in policing :) Try looking for his excellent posts
> regarding the
> policing in 2005/2006 years archieves :)
>
> I'll try to give a short explanation of things going here. To begin with,
> how does policer
> work, in short?
>
> Imagine you have 100Mb interface, and you want to limit outgoing traffic
> flow to
> 10Mbs. A big bunch of packets arrives, and is ready to be sent. Now, what
> policer does in such situation?.
>
> Well, it starts sending packet, at *interface* bitrate. How could we
> achieve the
> desired 10M target rate now? Of course, only by using some *averaging*.
> Look, If we
> drop some packets in line, instead of sending them, then total amount of
> traffic
> *sent* at 100Mbs would be lower than received amount (at the same time
> interval),
> and hence, the *average* speed (not interface sending bitrate!) would be
> reduced.
>
> So here comes the question: how much of the packets we may permit, before
> starting the drops? This question is answered by the "normal burst" value,
>
> which tells us, how many packets in line we can send at wire speed, w/o
> any drops. As soon as this value is exeeced, and there are more packets
> arriving
> we start dropping them, to accomodate the *average* speed. Of course,
> while
> we drop packets, the timer is ticking, and soon we'll have enough credits
> to send
> a packet again. This is a simple way to achieve desired average rate, and
> this
> is how actually policer works. (As a matter of fact, real policer "marks"
> packets -
> this a generic behavior, but with drop as a mark action, my decription
> seems to be ok).
>
> Note that policer work is very effective - it does not do any buffering,
> and it only keeps
> one variable - current bucket size - to track the marking behavior.
>
> Now you see, that burst size actually defines how "long" is you averaging
> overall.
> The larger is your burst, the more sustainable local "spikes" you permit
> (sudden
> quick burst at 100mbs from my example). But after all, the measure average
> bit
> rate would still be the target 10M (again from my example).
>
> --
>
> And finally,a comment about 3550 - it only implements single rate, two
> color policer.
> This means, that only one burst value is available for tuning - the normal
> burst.
>
> Now if your normal burst is specified in Bps, then maybe you need to
> convert it
> into bytes somehow... Multiply it by 1 second and divide by 8:
>
> 128000*1s/8bits = 32000 bytes.
>
> HTH
>
>
>
-- Petr Lapukhov, CCIE #16379 petr@internetworkexpert.comInternetwork Expert, Inc. http://www.InternetworkExpert.com Toll Free: 877-224-8987 Outside US: 775-826-4344
This archive was generated by hypermail 2.1.4 : Fri Dec 01 2006 - 08:05:48 ART