From: Howard C. Berkowitz (hcb@gettcomm.com)
Date: Wed Jun 25 2003 - 18:22:34 GMT-3
At 4:02 PM -0500 6/25/03, John Humphrey wrote:
>Posted this before but didn't get a response, so here I go again :)
>
>After reading the following CCO Doc:
>http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fq
>os_c/fqcprt2/qcfconmg.htm#1001336
>
>you will see the following special note that seems to negate the need to
>do all the normalize, divide, multipy stuff. The doc reads
>
>" CQ was modified in Cisco IOS Release 12.1. When the queue is depleted
>early, or the last packet from the queue does not exactly match the
>configured byte count, the amount of deficit is remembered and accounted
>for the next time the queue is serviced. Beginning with Cisco IOS Release
>12.1, you need not be as accurate in specifying byte counts as you did
>when using earlier Cisco IOS releases that did not take deficit into
>account. "
>
>Does this mean that we can use simple ratios for the byte-count
>calculations? For example, if I need to give three separate protocols 33%
>of the bandwidth, can I do "byte-count 500" for all three? It seems that
>if the IOS is capable of remembering the byte-count deficit, that using
>simple percentages should be OK. Any ideas would be appreciated.
>
Well, yes, but there are warnings involved. Yes, it's true that
remembering the deficit will make the long-term statistical
allocation of bandwidth more accurate with less effort.
The problem, however, is that if you'v not estimated well (i.e., used
estimates that reasonably reflect the average packet size), you will
get short term peaks and valleys in the throughput per class. That
may be OK for non-interactive traffic, but bad for interactive and
catastrophic for real-time.
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:09 GMT-3