From: yu chunyan (yuchunyan@hotmail.com)
Date: Tue Jul 22 2003 - 20:26:56 GMT-3
the 75% factor works in CBWFQ. I have try to set up CBWFQ with assumption of
100% factor. it do not work. IOS reminds you that no enough bandwidth for
default class and gives the remaining available bandwith. I check the value.
find 75% factor is considered for IOS.
Bin Lei
>From: Hossam <sam6626@yahoo.com>
>Reply-To: Hossam <sam6626@yahoo.com>
>To: badger <badger@pongo.org>
>CC: ccielab@groupstudy.com
>Subject: Re: Re[7]: QOS CBWFQ to Custom Queuing (again)
>Date: Mon, 21 Jul 2003 02:39:27 -0700 (PDT)
>
>Hi Group,
>
>I know this has been discussed so many times. Only one of them was really
>fruitful. But even in this fruitful discussion I didnt find a real
>convincing reason that we need to use the (75%) factor in these
>calculations.
>
> Sorry for not recalling names. But someone said that another one
>convinced him that the 75% is a must in a private discussion. But
>unfortunately we didnt get this private discussion.
>
> With all respect and understanding, I still dont find the logic behind
>using this multiplier. Here is the way I see it.
>
> Max. Reservable Bandwidth Definition:
>
> * The max. Available BW on any interface to be reserved for LLQ,
>RTP and RSVP.
>
> * Cisco recommends that we do't change the default (75%) to keep at
>least the rest 25% to the system traffic and other non priority traffic.
>
> From this understanding I think that this value never kicks in unless
>someone tries to reserve BW that is more than the 75% (Reserve means LLQ,
>Priority RTP, RSVp...etc). The 75% will prevent the configuration from
>exceeding this limit.
>
> Otherwise the 75% is not in the image at all. It never enters the BW
>calculations or scheduling traffic.
>
> In our CQ case we dont have any priority queues unless we have (queue
>zero). I really dont see the 75% in the image at all.
>
> I know that I may be mistaken. But can anyone send me the above mentioned
>private discussion or just give me his understanding.
>
> Thanks
>
>Hossam
>
>
>
>badger <badger@pongo.org> wrote:
>Hello Jonathan,
>
>Sunday, July 20, 2003, 6:09:44 PM, you wrote:
>
>JVH> I'm guessing the conversion factor is 8 bits/Byte:
>
>JVH> 27 KiloBytes x 8 bits/Byte = 216 Kilobits
>
>
>JVH> -----Original Message-----
>JVH> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
>Of
>JVH> badger
>JVH> Sent: Sunday, July 20, 2003 3:07 PM
>JVH> To: Connie Nie
>JVH> Cc: Richard Boover; Jim Phillipo; ccielab@groupstudy.com;
>JVH> 'brian@cyscoexpert.com'; 'Peter'
>JVH> Subject: Re[4]: QOS CBWFQ to Custom Queuing (again)
>
>
>JVH> Hello Connie,
>
>JVH> Sunday, July 20, 2003, 7:50:12 AM, you wrote:
>
>CN>> There was a thread about this before. One opinion is that the CBWFQ
>CN>> bandwidth should (in telnet's example): 14.8%x256x75% ---because the
>JVH> total
>CN>> reservable bandwidth by default in CBWFQ is 75% of the bandwidth.
>
>CN>> Connie
>
>JVH> Still confused, 75% of the original 256k is 192K. So my question
>JVH> still stands, where did the "8" come from ?
>
>JVH> Sometimes I need pictures to help explain 8-)
>
>
>CN>> Jim,
>
>CN>> How did you get the "8" in your:
>
>CN>> "convert Custom Queuing (KB) to CBWFQ (Kbps): 27KB x 8 = 216Kbps"
>
>
>
>
>
>Thanks, now it makes sense...as usual, I didn't look at it long enough
>to actually read it 8-( I may never pass the lab with these habits!
>
>--
>Best regards,
>badger mailto:badger@pongo.org
>
>
>_______________________________________________________________________
>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
>
>---------------------------------
>Do you Yahoo!?
>SBC Yahoo! DSL - Now only $29.95 per month!
>
>
>_______________________________________________________________________
>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
This archive was generated by hypermail 2.1.4 : Wed Aug 06 2003 - 06:52:49 GMT-3