From: Andrew Bratchell (a.bratchell@xxxxxxxxx)
Date: Tue Mar 12 2002 - 09:57:21 GMT-3
CL,
This is an extract from my study notes.
Custom Queuing
CQ reserves a percentage of the available bandwidth of an interface for each
selected traffic type. If a particular type of traffic is not using the
bandwidth reserved for it, then other traffic types may use the remaining
reserved bandwidth. CQ guarantees some level of service to all traffic
because you can allocate bandwidth to all classes of traffic. You can define
the size of the queue by determining its configured packet-count capacity,
thereby controlling bandwidth access. You can classify traffic into 16
queues.
With custom queuing, the router sends packets from a particular queue until
the byte count is exceeded. Even after the byte count value is exceeded, the
packet currently being transmitted is completely sent. Thus, if you set your
byte count to 100 bytes and your protcol's packet size is 512 bytes,
everytime the queue is serviced, 512 bytes are sent NOT 100 bytes.
If you want to split bandwidth evenly across all of your protocols, you may
think that defining the same byte count will do the trick - this is wrong.
As a example consider the following :-
You have three protocols, with packet sizes of 500, 300 and 100 bytes
respectively. If you specify a byte counts of 200,200 and 200 for each queue
this configuration does not result in a 33/33/33 ratio. You get a ratio of
50/30/20. This is because when the router services the first queue it sends
a 500 bytes packet, second queue a 300 byte packet and third queue two 100
byte packets.
To get the bandwidth ratio's you require based on a given packet size for a
protcol requires some maths. Consider the following scenario. A network
administrator wants to allocate bandwidth to protocols A, B and C with 75%,
20% and 5% respectively. The average packet size for protocol A is 1024
bytes, protocol B is 512 bytes and protocol C is 800 bytes. To determine the
correct byte counts do the following :-
1) For each queue you want, divide the percentage of bandwidth you need to
allocate to the queue by the packet size in bytes.
70:1024, 20:512, 5:800 or
0.0683, 0.0390, 0.0062
2) Normalise the numbers by dividing each by the lowest number.
0.0683 \ 0.0062 = 11.01
0.0390 \ 0.0062 = 6.29
0.0062 \ 0.0062 = 1
3) A fraction in any of the ratio values means an additional packet send.
Round up the numbers to the next whole number to obtain the actual packet
output. Therefore here it will be 12, 7, 1
4) Convert the packet number ratio into byte counts by multiplying each
packet count by the corresponding packet size. Therefore, the number of
packets sent is twelve 1024-byte packets, seven 512-byte packets and one
800-byte packets or 12288, 3584, and 800 respectively. These are the byte
counts you would specify in your custom queueing configuration.
5) To determine the bandwidth distribution this ratio represents, first
determine the total number of bytes after all three queues are services.
(12 x 1024) + (7 x 512) + (1 x 800) = 12228 + 3584 + 800 = 16612
6) To determine the percentage of the total number of bytes sent from each
queue :
12288\16612 = 73%
3584 \ 16612 = 21.6%
800 \ 16612 = 4.8%
This is fairly close to the ratio of 75:20:5.
7) If the actual bandwidth is not close enough to the desired bandwidth,
multiply the original ratio of 11.01 : 6.29 : 1 in step 2 by the best value,
in order to get the ratio as close three integer values as you can. This
multiplier does not have to be an integer itself.
Hope this helps you.
Andy
-----Original Message-----
From: Crystal Lee [mailto:crystaleeeeee@yahoo.com]
Sent: 12 March 2002 12:28
To: ccielab@groupstudy.com
Subject: CQ on Byte count
Hi everyone ,
I am trying to understand how byte count works on custom queuing. I have
checked the one on univeral CD but the example wasn't quite good. does
anyone have a better doc on byte count.
Thanks for your help in advance,
cl
---------------------------------
Do You Yahoo!?
Try FREE Yahoo! Mail - the world's greatest free email!
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:01 GMT-3