Well, let's talk about the burst parameter, because I believe we
reached a conclusion it does not work like Bc (i.e. to determine the
Tc). Rather it works more closely to Be, but not even that... :-)
I'm not confused about it - I just can't seem to find the information
what it does. I can *believe* what it does, but that doesn't explain
it to me ;-)
-- Marko Milivojevic - CCIE #18427 (SP R&S) Senior CCIE Instructor - IPexpert On Tue, Dec 18, 2012 at 3:30 PM, Narbik Kocharians <narbikk_at_gmail.com> wrote: > I have not, why would you say that? I am not going to participate in you > said he said stuff. The burst in LLQ works the way I explained it, and I > still say that, when did I say the burst does not work the way i mentioned? > > The burst in LLQ works just like the Bc in a single rate 2 color policer. > NOW...whether it's behavior is that way during congestion or not it needs to > be tested, I believe it works that way during congestion, but i do not have > the testing gear to provide results, the tests shown in some of the examples > are ridiculous to test the complete package, things like burst and playing > with the burst value. > > It was you that was confused about the burst parameter and not me. Go back > and read what you wrote. > > > On Tue, Dec 18, 2012 at 3:15 PM, Marko Milivojevic <markom_at_ipexpert.com> > wrote: >> >> Thank you for agreeing with what I was saying all along (even though >> it kind-of contradicts your previous burst statement) ;-) >> >> Now, testing LLQ is tricky and making calls is not exactly the best >> way to test it, should you intend to use it for something other than >> voice. Any throughput, queueing, performance testing is best left to >> the professional tools designed for that purpose. Human ears are not a >> good tool :-). >> >> For anyone with (serious) production concerns about the LLQ and a >> (serious) testing budget, I can only highly recommend Spirent >> SmartBits or TestCenter products. They are *unparalleled* to what >> you'll be able to learn about your routers and switches and their >> (lack of) performance... :-) >> >> -- >> Marko Milivojevic - CCIE #18427 (SP R&S) >> Senior CCIE Instructor - IPexpert >> >> On Tue, Dec 18, 2012 at 3:09 PM, Narbik Kocharians <narbikk_at_gmail.com> >> wrote: >> > Totally agree with what was stated in that link. >> > We have to remember that PQ, CBWFQ, are all congestion management tool. >> > but >> > the best way to test LLQ is to actually make calls and test the quality. >> > >> > On Tue, Dec 18, 2012 at 2:40 PM, Joe Sanchez <marco207p_at_gmail.com> >> > wrote: >> >> >> >> Here is a great view: >> >> >> >> >> >> >> >> http://www.cisco.com/en/US/docs/ios/12_0t/12_0t7/feature/guide/pqcbwfq.html#wp5329 >> >> >> >> JS >> >> >> >> On Tue, Dec 18, 2012 at 3:28 PM, Marko Milivojevic >> >> <markom_at_ipexpert.com> >> >> wrote: >> >>> >> >>> For fun, I added another source of the traffic and lowered bandwidth >> >>> on the interface to 768000 (in an attempt to actually create a >> >>> congestion). This is by no means an exhaustive test of LLQ and the >> >>> quality, but it shows a conditional policer in action. >> >>> >> >>> ------------------------------8<------------------------------ >> >>> !!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!! >> >>> !!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >> >>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!! >> >>> !!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!! >> >>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!! >> >>> !!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!! >> >>> !!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!! >> >>> !!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!! >> >>> !!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!! >> >>> !!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! >> >>> !!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! >> >>> !.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!! >> >>> !!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!! >> >>> !!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!! >> >>> !!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!! >> >>> !!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!! >> >>> !!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!! >> >>> !!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!! >> >>> !!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.!!!!!!!!!!!!!!!!!!!!!!!! >> >>> ------------------------------8<------------------------------ >> >>> >> >>> If you look closely at the pattern of drops above, you will observe >> >>> the regular intervals at which they appear. This *can* be an indicator >> >>> of active traffic conditioner. Let's see what our policy says. Keep in >> >>> mind that the other traffic generator is much more aggressive than the >> >>> first (timeout 0). >> >>> >> >>> ------------------------------8<------------------------------ >> >>> R2#show policy-map interface Serial0/2/0 output class PRIORITY >> >>> >> >>> Serial0/2/0 >> >>> >> >>> Service-policy output: LLQ >> >>> >> >>> queue stats for all priority classes: >> >>> >> >>> queue limit 64 packets >> >>> (queue depth/total drops/no-buffer drops) 0/0/0 >> >>> (pkts output/bytes output) 158281/238054624 >> >>> >> >>> Class-map: PRIORITY (match-all) >> >>> 344671 packets, 518385060 bytes >> >>> 30 second offered rate 10173000 bps, drop rate 9649000 bps >> >>> Match: protocol icmp >> >>> Priority: 100 kbps, burst bytes 2500, b/w exceed drops: 186359 >> >>> ------------------------------8<------------------------------ >> >>> >> >>> The problem is that this test is flawed when it comes to reproducing >> >>> the real congestion, as here we also have to take into account that >> >>> the traffic is arriving from the same input interface, so we have 1:1 >> >>> input:output mapping (again, something I mentioned very early in this >> >>> thread as an important factor). >> >>> >> >>> I could spend even more time labbing it up for you, but I suppose I've >> >>> done enough train-the-trainer for one day :-). >> >>> >> >>> -- >> >>> Marko Milivojevic - CCIE #18427 (SP R&S) >> >>> Senior CCIE Instructor - IPexpert >> >>> >> >>> On Tue, Dec 18, 2012 at 1:16 PM, Marko Milivojevic >> >>> <markom_at_ipexpert.com> >> >>> wrote: >> >>> > On Tue, Dec 18, 2012 at 1:14 PM, Narbik Kocharians >> >>> > <narbikk_at_gmail.com> >> >>> > wrote: >> >>> >> How did you prove that LLQ kicks in during congestion? How did you >> >>> >> measure >> >>> >> the quality of these packets? >> >>> > >> >>> > Well, that's not at all what I was testing, as the test was built >> >>> > specifically to avoid congestion to show how there's no policing >> >>> > when >> >>> > congestion does not occur. Apples and Oranges. >> >>> > >> >>> > Testing the quality of these packets would be difficult (not >> >>> > impossible) to measure using IOS-only and Voice SLA probes as >> >>> > traffic >> >>> > generators, but as I said... this was not the point here. >> >>> > >> >>> > -- >> >>> > Marko Milivojevic - CCIE #18427 (SP R&S) >> >>> > Senior CCIE Instructor - IPexpert >> >>> >> >>> >> >>> Blogs and organic groups at http://www.ccie.net >> >>> >> >>> >> >>> _______________________________________________________________________ >> >>> Subscription information may be found at: >> >>> http://www.groupstudy.com/list/CCIELab.html >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> > >> > >> > >> > -- >> > Narbik Kocharians >> > CCSI#30832, CCIE# 12410 (R&S, SP, Security) >> > www.MicronicsTraining.com >> > Sr. Technical Instructor >> > YES! We take Cisco Learning Credits! >> > A Cisco Learning Partner >> > > > > > > -- > Narbik Kocharians > CCSI#30832, CCIE# 12410 (R&S, SP, Security) > www.MicronicsTraining.com > Sr. Technical Instructor > YES! We take Cisco Learning Credits! > A Cisco Learning Partner Blogs and organic groups at http://www.ccie.netReceived on Tue Dec 18 2012 - 15:33:18 ART
This archive was generated by hypermail 2.2.0 : Tue Jan 01 2013 - 09:36:53 ART