This is something I am researching currently. I believe LLQ is CBWFQ+PQ and the PQ is strict. This means that anything above the allocated rate is dropped. This is fine for voice traffic where you reserve say 200kbps for 8 voice calls, and anything more than that is dropped, but not suitable for data applications. You will need to use CBWFQ for your data apps, not place them in the PQ.
The CBWFQ will guarantee bandwidth to PC1 as you mention in your first post. I would say that the PQ only gives you 30k due to slow start after packet loss. Finally, why CBWFQ gives you sometimes 100k, sometimes 50k, - I can understand it giving you more than 80k, if there is more available, but I'm not sure why it gave you less. Perhaps the application or operating system applied some congestion control. I believe Win2k or XP does a lot of good work to not hog all of the WAN bandwidth. At this stage, I would question the appropriateness of FTP as an accurate traffic generation tool. As to the ping times, your bandwidth under the priority condition is only guaranteed up to the amount reserved. Anything above that is dropped if the Q is strict. PC1 would get better response if the ping traffic was in the PQ, but it isn't so it is placed in the same Q as all the FTP traffic. Then within the PQ, your ping has to sit at the end of a bunch of FTP data. I wouldn't be surprised if your ping traffic from PC1 was actually worse that PC2. PC2, under CBWFQ, would be more fair to small ping packets than many large FTP packets. Rik -----Original Message----- From: Ivan Yip [mailto:[EMAIL PROTECTED]] Sent: Monday, 30 December 2002 12:07 PM To: [EMAIL PROTECTED] Subject: RE: FR Low Latency Queuing (LLQ) [7:59820] Hi, I got the following information during debug. 128K_LL#debug priority Priority output queueing debugging is on 128K_LL# 3d01h: now 263877385 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877750 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263877754 tokens 4288 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 3d01h: now 263878034 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263878307 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263878764 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263879040 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263879132 tokens 16000 pak_size 8096 max_token_limit 16000 3d01h: now 263879653 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880046 tokens 16000 pak_size 512 max_token_limit 16000 3d01h: now 263880202 tokens 16000 pak_size 12032 max_token_limit 16000 3d01h: now 263880202 tokens 3968 pak_size 12032 max_token_limit 16000 3d01h: WFQ: dropping a packet from the priority queue 1 ............. Also, I found there is packet drops on the match ip address. The 'priority 80' is configured but there have a lot of dropped packets but default packet have no drop. Why? 128K_LL#show policy-map interface serial 0/0.1 Serial0/0.1: DLCI 200 - Service-policy output: 1 Class-map: 1 (match-all) 15552 packets, 16947920 bytes 30 second offered rate 30000 bps, drop rate 7000 bps Match: access-group 21 Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 80 (kbps) Burst 2000 (Bytes) (pkts matched/bytes matched) 2531/1983899 (total drops/bytes drops) 333/495184 Class-map: class-default (match-any) 18281 packets, 22054542 bytes 30 second offered rate 104000 bps, drop rate 0 bps Match: any 128K_LL#show policy-map 1 Policy Map 1 Class 1 Strict Priority Bandwidth 80 (kbps) Burst 2000 (Bytes) It looks like the guaranteed bandwidth 80 was dropped first instead of the default packet? Why? Thanks again. rgds, ivan Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59942&t=59820 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
