From: glmorris48 (glmorris48@xxxxxxxxxxx)
Date: Thu Apr 04 2002 - 13:09:18 GMT-3
Assuming your average byte counts for both IP and IPX were 1500, your
philosophy would work fine. However, it is unlikely that this is going to
be the case and you will find that your solution does not meet the the
requirements of the problem.
----- Original Message -----
From: "Todd Carswell" <acarswell@nc.rr.com>
To: "Zhang, Stan" <stan.zhang@verizon.com>; "'Shaun Wakelen'"
<Shaun.Wakelen@telindus.co.uk>; <steven.j.nelson@bt.com>;
<ccielab@groupstudy.com>
Sent: Thursday, April 04, 2002 7:52 AM
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