From: Hossam Mahmoud (sam6626@yahoo.com)
Date: Mon Jun 02 2003 - 18:17:41 GMT-3
I think that the proposed solution :
queue-list 1 protocol ip 1
queue-list 1 pro ip 2 tcp 2065
queue-list 1 protocol ipx 3
queue-list 1 protocol ip 4 tcp telnet
queue-list 1 queue 1 byte-count 9000
queue-list 1 queue 2 byte-count 9000
queue-list 1 queue 3 byte-count 7500
queue-list 1 queue 4 byte-count 4500
Provides the same BW as the following solution
queue-list 1 protocol ip 1
queue-list 1 pro ip 2 tcp 2065
queue-list 1 protocol ipx 3
queue-list 1 protocol ip 4 tcp telnet
queue-list 1 queue 1 byte-count 3000
queue-list 1 queue 2 byte-count 3000
queue-list 1 queue 3 byte-count 2490
queue-list 1 queue 4 byte-count 1500
The only advantage of the last one is using lower queues length. Meaing better performance. Or we better say more predictable and consistant performance.
In real life i would go for the last one.
In the LAB, i am really not sure what will they expect. And i would say that it will depand a lot on the requirements wording.
I wish we can reach a more solid agreement.
Any recommendations??
Thanks,
SAM
Jason Cash <cash2001@swbell.net> wrote:
I agree with you calculations, but the solution that they provided was:
queue-list 1 protocol ip 1
queue-list 1 pro ip 2 tcp 2065
queue-list 1 protocol ipx 3
queue-list 1 protocol ip 4 tcp telnet
queue-list 1 queue 1 byte-count 9000
queue-list 1 queue 2 byte-count 9000
queue-list 1 queue 3 byte-count 7500
queue-list 1 queue 4 byte-count 4500
So how would the solution you came up with 3000/3000/2490/1500 be incorrect
when, fractionally, they are the same? If I were to use the "3000" count,
would that be considered incorrect?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Hossam Mahmoud
Sent: Monday, June 02, 2003 11:37 AM
To: Jason Cash; 'Nguyen Hoang Long'; ccielab@groupstudy.com
Pals,
Yes!!In all versions they use the same calulcation method. And in both 12.1
and 12.2 documentations they mention the new borrowing technique that
"Nguyen " is talking about.
So i think we HAVE!!! to conclude that the new technique is not related to
calculation method.
Giving it a second thought i would say the following:
1- The two calculation methods gives almost the same results with slight two
differnaces. First, the accuraccy of the BW distribution between queues.The
documentation calculation technique is less accurate than "Nguyen" method.
Second the length of the queues. "Nguyen" method gives higher queues length.
2- Accurate BW distribution is surly prefered.
3- But High queues length is not recommended. It may cause unexpected jerky
performance. This jerky performance will be caused due to the fact of
serving shorter queues gives more predictable delays for other queues.
So we have to compromise here.And i think we would rather accept a less
accurate BW distribution more than jerky unexpected performance. Or at least
that is what the documentation says!!!
As far as i think NOW (not final yet) the new technique for handling queues
will only affect one step in the documentation calculation technique. Here
is the documentation calculation method after applying this change.
Calculation Method:
____________________________________________
Here is what I do (average pkt 1500)
1) For each queue, divide the percentage of bandwidth you want to
allocate to the queue by the packet size, in bytes.
30/1500 = .02
30/1500 = .02
25/1500 = .0166
15/1500 = .01
2) Normalize the numbers by dividing by the lowest number:
.02/.01 = 2
.02/.01 = 2
.0166/.01 = 1.66
.01/.01 = 1
3) A fraction in any of the ratio values means that an additional packet
will be sent
(THIS IS WHERE THE NEW Queues handling technique shows up!!!).
The new technique will allow to serve the additional packet once and will
take this in acount
to decrease the serverd bytes in the second cycle serving this queue.
From my understanding to the new technique, I do't think that we need to do
this approx.
any more.
(Please note that if we choosed the factor 3 here!! we will reach the same
values as we
get if we use "Nguyen" method. But as i said before this will affect the
queues lenght
and hence performance.)
IP = 2
SNA = 2
IPX = 1.66
Telnet = 1
4) Convert the packet number ratio into byte counts by multiplying
each packet count by the corresponding packet size.
IP = 1500x2 = 3000
SNA = 1500x2 = 3000
IPX = 1500x1.66 = 2490
Telnet = 1500x1 = 1500
5) To determine the bandwidth distribution this ratio represents,
first determine the total number of bytes sent after all three queues are
serviced:
Based on my info above I get: 3000+3000+2490+1500= 9990
6) Then determine the percentage of the total number of bytes sent
from each queue:
IP = 3000/9990 = .3 (30%)
SNA = 3000/9990 = .3 (30%)
IPX = 2490/9990 = .249 (24.9%)
Telnet = 1500/9990= .15 (15%)
What do u all think?? Is it convencing???
Waiting for yr opinions!!
Thanks a lot
SAM
Jason Cash wrote:
One more then and I think this horse will be dead.
Based on that information, that being with the changes to 12.1 how should
queues be determined? Even in that link, the example is given with the
antiquated byte count determination.
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nguyen Hoang Long
Sent: Monday, June 02, 2003 2:24 AM
To: Hossam Mahmoud; Jason Cash; ccielab@groupstudy.com
Hossam,
check this:
http://127.0.0.1:8080/cc/td/doc/product/software/ios122/122cgcr/fqos_c/fqcpr
t
2/qcfconmg.htm#xtocid47
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.
----- Original Message -----
From: Hossam Mahmoud
To: Jason Cash ; 'Nguyen Hoang Long' ; ccielab@groupstudy.com
Sent: Monday, June 02, 2003 1:34 PM
Subject: RE: Custom Queue Confusion
I agree with you but do u know exactly which IOS version supports the new
borrowing technique.
As far as i know the LAB is still using 12.1. IOS ver 12.1 documentation
is
using the same calulation method used by Jason in his initial mail!!
So i think this is the calculation method expected at LABS.....is't it??
Thanks for advise
SAM
Jason Cash wrote:
That actually is the correct answer, but how did you come to get:
30:30:25:15 = 6:6:5:3 ?
How did you know to divide by 5 to get 6:6:5:3? Or did you use some
other
calculation?
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Nguyen Hoang Long
Sent: Sunday, June 01, 2003 2:54 AM
To: Jason Cash; ccielab@groupstudy.com
Hi Jason,
I would do by this way for exact ratio:
IP:SNA:IPX:telnet = 30:30:25:15 = 6:6:5:3
therefore:
IP = 1500x6 = 9000 (30%)
SNA = 1500x6 = 9000 (30%)
IPX = 1500x5 = 7500 (25%)
Telnet = 1500x3 = 4500 (15%)
Since we're using new IOS, which permits the router to borrow from the
next
queue for a current queue, your calculation method is not necessary. I
prefer a more simple method.
Long
----- Original Message -----
From: "Jason Cash"
To:
Sent: Sunday, June 01, 2003 12:28 PM
Subject: Custom Queue Confusion
> I am getting really confused on the custom queuing! I have looked over
the
> previously provided links, but those examples don't address the
problem
I
am
> having. Whereas I am instructed:
>
>
>
> IP traffic 30% bw
>
> SNA traffic 30% bw
>
> IPX traffic 25% bw
>
> Telnet traffic 15% bw
>
>
>
> Here is what I do (average pkt 1500)
>
> 1) For each queue, divide the percentage of bandwidth you want to
allocate
> to the queue by the packet size, in bytes.
>
> 30/1500 = .02
>
> 30/1500 = .02
>
> 25/1500 = .0166
>
> 15/1500 = .01
>
>
>
> 2) Normalize the numbers by dividing by the lowest number:
>
> .02/.01 = 2
>
> .02/.01 = 2
>
> .0166/.01 = 1.66
>
> .01/.01 = 1
>
>
>
> 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.
>
> IP = 2
>
> SNA = 2
>
> IPX = 2
>
> Telnet = 1
>
>
>
> 4) Convert the packet number ratio into byte counts by multiplying
each
> packet count by the corresponding packet size.
>
> IP = 1500x2 = 3000
>
> SNA = 1500x2 = 3000
>
> IPX = 1500x2 = 3000
>
> Telnet = 1500x1 = 1500
>
>
>
> Now here is one place I get lost. IPX byte count is the same as IP and
SNA
> and I know that can't be right, but what do I do? 2 is the only
multiple
to
> go by.
>
>
>
> 5) To determine the bandwidth distribution this ratio represents,
first
> determine the total number of bytes sent after all three queues are
> serviced:
>
> Based on my info above I get: 3000+3000+3000+1500= 10500
>
>
>
> 6) Then determine the percentage of the total number of bytes sent
from
each
> queue:
>
> IP = 3000/10500 = .28 (28%)
>
> SNA = 3000/10500 = .28 (28%)
>
> IPX = 3000/10500 = .28 (28%)
>
> Telnet = 1500/10500= .14 (14%)
>
>
>
> This adds up to 98%. So I will wait for some advice before I proceed.
> Basically, when I a queue is rounded up and is equal to a greater
queue,
how
> is that queues byte count determined?
----------------------------------------------------------------------------
-
-
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
---------------------------------
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
---------------------------------
Do you Yahoo!?
Free online calendar with sync to Outlook(TM).
This archive was generated by hypermail 2.1.4 : Fri Jul 04 2003 - 11:10:51 GMT-3