From: Carlos G Mendioroz (tron@huapi.ba.ar)
Date: Wed Jun 25 2003 - 20:11:51 GMT-3
Howard,
I don't see how what you say can happen.
Would it be possible for you to come up with a simple example where a
ratio assignment would generate high short term throughput variability,
and a good matching with one calculated by normalize/divide/multiply
stuff ?
Using big numbers may do, but using ratios it would be easier to
actually use smaller numbers anyway.
Thank you,
-Carlos
Howard C. Berkowitz wrote:
> 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.
>
>
> _______________________________________________________________________
> You are subscribed to the GroupStudy.com CCIE R&S Discussion Group.
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
-- Carlos G Mendioroz <tron@huapi.ba.ar> LW7 EQI Argentina
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:11:09 GMT-3