RE: Custom Queueing (Again)

From: Ferguson, Francis (Francis_Ferguson@xxxxxxxxxxx)
Date: Thu Apr 04 2002 - 13:20:09 GMT-3


   
here is a simple easy way to calculate bandwidth for custom queues

Example create queues with 30% 20% 12% 18% 10% and 10%

pick a byte number (any number),100 for instance and multiple each value by
the percentage required
what you get 3000,2000,1200,1800,1000 and 1000 for the

if you would like a particular queue size for one queue i.e.(30% = 4500)
then the base byte number is (4500/30 = 150)
 now your queues look like this

4500 3000 1800 2700 1500 1500

-----Original Message-----
From: Todd Carswell [mailto:acarswell@nc.rr.com]
Sent: Thursday, April 04, 2002 8:53 AM
To: Zhang, Stan; 'Shaun Wakelen'; steven.j.nelson@bt.com;
ccielab@groupstudy.com
Subject: Re: Custom Queueing (Again)

I don't use any formulas to calculate the byte-counts. I just think about
how many packets will fit in the queue when I start figuring out the
byte-counts. If I start monkeying around with a stinkin' formula on the
exam, I can easily get flustered and screw up my "plutification". To keep
it simple for myself, I think of it like this...

The average packet is 1024 bytes, from what I've gathered thus far. I'd
like to fit more than 1 packet in the queue at any given time, so I make my
smallest queue at least 2048 bytes.

Since I am a bit fond of nice round numbers, I would just bump that number
up to 3000 bytes to accomodate two packets of the maximum size of 1500
bytes. From there, I'd figure out the rest of the queue sizes based upon
how much bandwidth I'd like to allocate.

Example: 50% to IP, 25% IPX, 25% default

queue-list 1 protocol ip 1
queue-list 1 protocol bridge 2
queue-list 1 protocol dlsw 3
queue-list 1 queue 1 byte-count 6000
queue-list 1 queue 2 byte-count 3000
queue-list 1 queue 3 byte-count 3000

Keep It Simple!!!

Todd Carswell

----- Original Message -----
From: "Zhang, Stan" <stan.zhang@verizon.com>
To: "'Shaun Wakelen'" <Shaun.Wakelen@telindus.co.uk>;
<steven.j.nelson@bt.com>; <ccielab@groupstudy.com>
Sent: Thursday, April 04, 2002 9:14 AM
Subject: RE: Custom Queueing (Again)

> Steve,
>
> There is another way of doing that. Instead of using division, you can
use
> multiplication to derive the common denominator. Either way works fine,
and
> both methods take about equal amount of time. I would have to concur with
> Shaun and say stick with what you know best, it'll always be there when
you
> need it. Best of the luck.
>
>
> Stan Zhang
>
>
>
> -----Original Message-----
> From: Shaun Wakelen [mailto:Shaun.Wakelen@telindus.co.uk]
> Sent: Thursday, April 04, 2002 7:45 AM
> To: steven.j.nelson@bt.com; ccielab@groupstudy.com
> Subject: RE: Custom Queueing (Again)
>
>
> Steve
>
> That is the formula I was shown and now use. I have seen other ways posted
> on here, which seem more complicated, but that may be down to the fact I
> have not done it that way. Stick with what you know best. If you know it
> gives the correct result, and you have to use it, then the points are in
the
> bag!
>
> Shaun
>
> -----Original Message-----
> From: steven.j.nelson@bt.com [mailto:steven.j.nelson@bt.com]
> Sent: 04 April 2002 13:26
> To: ccielab@groupstudy.com
> Subject: Custom Queueing (Again)
>
>
> All
>
> What is the simplest formula for working out bandwidth allocation when
using
> custom queueing.
>
> I have been using the following but I am looking for a quicker way.
>
> Step 1 For each queue, divide the percentage of bandwidth you want to
> allocate to the queue by the packet size, in bytes. For example, assume
the
> packet size for protocol A is 1086 bytes, protocol B is 291 bytes, and
> protocol C is 831 bytes. We want to allocate 20 percent for A, 60 percent
> for B, and 20 percent for C. The ratios would be:
>
> 20/1086, 60/291, 20/831 or
>
> 0.01842, 0.20619, 0.02407
>
> Step 2 Normalize the numbers by dividing by the lowest number:
>
> 1, 11.2, 1.3
>
> The result is the ratio of the number of packets that must be sent so that
> the percentage of bandwidth that each protocol uses is approximately 20,
60,
> and 20 percent.
>
> Step 3 A fraction in any of the ratio values means that an additional
packet
> will be sent. Round up the numbers to the next whole number to obtain the
> actual packet count.
>
> In this example, the actual ratio will be 1 packet, 12 packets, and 2
> packets.
>
> Step 4 Convert the packet number ratio into byte counts by multiplying
each
> packet count by the corresponding packet size.
> In this example, the number of packets sent is one 1086-byte packet,
twelve
> 291-byte packets, and two 831-byte packets or
> 1086, 3492, and 1662 bytes, respectively, from each queue. These are the
> byte counts you would specify in your custom
> queueing configuration.
>
> Step 5 To determine the bandwidth distribution this ratio represents,
first
> determine the total number of bytes sent after all three queues are
> serviced:
>
> (1 x 1086) + (12 x 291) +(2 x 831) = 1086 + 3492 + 1662 = 6240
>
> Step 6 Then determine the percentage of the total number of bytes sent
from
> each queue:
>
> 1086/6240, 3492/6240, 1662/6240 = 17.4, 56, and 26.6 percent
>
> As you can see, this is close to the desired ratio of 20/60/20.
>
>
>
> Steve Nelson
> Customer Engineer
> BT Ignite- National Solutions
> T: +44 (0)1422 338881 M: +44 (0)7811 944172
> e-mail: steven.j.nelson@bt.com
> pp HW A170, PO Box 200(HOM-NZ), London, N18 1ZF
> > British Telecommunications plc
> > Registered office: 81 Newgate Street London EC1A 7AJ
> > Registered in England no. 1800000.
> > This electronic message contains information from British
> Telecommunications plc which may be privileged or confidential. The
> information is intended to be for the use of the individual(s) or entity
> named above. If you are not the intended recipient be aware that any
> disclosure, copying, distribution or use of the contents of this
information
> is prohibited. If you have received this electronic message in error,
please
> notify us by telephone or email (to the numbers or address above)
> immediately.



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:54 GMT-3