Hi anyone using sangoma hardware with lartc? pls let me know Thanks Imthiyaz Original Message: ----------------- From: lartc-request@xxxxxxxxxxxxxxx Date: Fri, 15 Jun 2007 12:00:07 +0200 (CEST) To: lartc@xxxxxxxxxxxxxxx Subject: LARTC Digest, Vol 28, Issue 23 Send LARTC mailing list submissions to lartc@xxxxxxxxxxxxxxx To subscribe or unsubscribe via the World Wide Web, visit http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc or, via email, send a message with subject or body 'help' to lartc-request@xxxxxxxxxxxxxxx You can reach the person managing the list at lartc-owner@xxxxxxxxxxxxxxx When replying, please edit your Subject line so it is more specific than "Re: Contents of LARTC digest..." Today's Topics: 1. RE: Re: PQ questions (Tim Enos) 2. Re: PQ questions (Christian Benvenuti) 3. RE: Re: PQ questions (Salim S I) 4. Re: PQ questions (Christian Benvenuti) 5. RE: Re: PQ questions (Salim S I) 6. RE: Re: multiple routing tables for internal router programs (Salim S I) ---------------------------------------------------------------------- Message: 1 Date: Fri, 15 Jun 2007 02:43:21 -0400 From: "Tim Enos" <tenos@xxxxxxxxxx> Subject: RE: Re: PQ questions To: "'Christian Benvenuti'" <christian.benvenuti@xxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Message-ID: <200706150643.l5F6hYeo015579@xxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" Hi Christian, Thanks for the help. Please see my in-line comments: > -----Original Message----- > From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > On Behalf Of Christian Benvenuti > Sent: Thursday, June 14, 2007 4:44 PM > To: lartc@xxxxxxxxxxxxxxx > Subject: Re: PQ questions > > Hi, > > >Hi all, > > > >First, let me say I've been most impressed with how quickly and > >professionally people on this list ask and answer questions. > > > >Next, let me say that with which I need help is properly configuring > strict > >PQ, and gathering certain stats. Specifically: > > > >- I need to create a priority queue with four queues (let's say they are > of > >high, medium, normal, and low priority) > > > >- I need to use tc filters such that: > > > > - EF (0xB8) goes to the high priority queue > > > > - AF21 (0x50) goes to the medium priority queue > > > > - AF11 (0x28) goes to the normal priority queue, and > > > > - BE traffic goes to the low priority queue > > > >- For stat collection, I need to see: > > > > - how many bytes and packets are in each of the four queues > > > >- My configuration thus far is: > > > >tc qdisc add dev eml_test root handle 1: prio bands 4 priomap 0 1 2 3 > > > >tc filter add dev eml_test parent 1:0 prio 1 protocol ip u32 match ip tos > >0xb8 0xff flowid 1:1 > > > >tc filter add dev eml_test parent 1:0 prio 2 protocol ip u32 match ip tos > >0x80 0xff flowid 1:2 > > > >tc filter add dev eml_test parent 1:0 prio 3 protocol ip u32 match ip tos > >0x50 0xff flowid 1:3 > > > >tc filter add dev eml_test parent 1:0 prio 4 protocol ip u32 match ip tos > >0x00 0xff flowid 1:4 > >__________ > > Here is an article you may find useful: > http://citeseer.ist.psu.edu/539891.html > > Here is the description of the configuration parameters of the > PRIO qdisc: > http://www.lartc.org/howto/lartc.qdisc.classful.html#AEN903 > (just in case you did not know what the "priomap" option is > used for) > > >My questions are: > > > >- What if anything is missing/requiring change in my config given the > stated > >requirements? > > Your config does not prevent an higher priority class from starving > a lower priority class. Exactly. That is requirement. > You can prevent it in two different ways (at > least): Don't want to prevent it right now. > > 1) You can assign a TBF qdisc (Token Bucket) to the PRIO classes > TBF: http://www.lartc.org/howto/lartc.qdisc.classless.html#AEN691 > > 2) You can replace the PRIO qdisc with something like HTB/CBQ > CBQ: http://www.lartc.org/howto/lartc.qdisc.classful.html#AEN939 > HTB: http://luxik.cdi.cz/~devik/qos/htb/ > > >- What if any command should I use to view how many bytes and packets are > in > >each of the four queues? > > The PRIO qdisc does not return statistics for its classes. > However, a simple workaround consists of explicitly adding > a qdisc to the four classes. > By default the PRIO qdisc assigns a pFIFO (packet FIFO) qdisc to > its classes. > Here is how you can replace the 4 default pFIFO qdisc with 4 > explicit pFIFO qdisc: > > tc qdisc add dev eml_test parent 1:1 pfifo limit 1000 > tc qdisc add dev eml_test parent 1:2 pfifo limit 1000 > tc qdisc add dev eml_test parent 1:3 pfifo limit 1000 > tc qdisc add dev eml_test parent 1:4 pfifo limit 1000 > > Now you can get the stats with: > tc -s -d qdisc list dev eml_test Those stats are nice to have, but the ones I must have are for how many bytes/packets are enqueued at whatever time I check the queues. > > Regards > /Christian > [ http://benve.info ] > I have tried to configure PQ to have two queues per filter with no success. Is it even possible to have (what I'll call) hierarchical PQ? I have yet to find it. > > > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ------------------------------ Message: 2 Date: Fri, 15 Jun 2007 09:32:06 +0200 From: Christian Benvenuti <christian.benvenuti@xxxxxxxxx> Subject: Re: PQ questions To: lartc@xxxxxxxxxxxxxxx Message-ID: <1181892726.2702.7.camel@benve-laptop> Content-Type: text/plain Hi, > > Your config does not prevent an higher priority class from starving > > a lower priority class. > > Exactly. That is requirement. OK > Those stats are nice to have, but the ones I must have are for how many > bytes/packets are enqueued at whatever time I check the queues. That information is there. Here is an example: (b=bytes p=packets) #tc -s -d qdisc list dev eth1 qdisc prio 1: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 85357186 bytes 59299 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 35p requeues 0 +-> This field is not initialized for this qdisc type qdisc pfifo 10: parent 1:1 limit 1000p Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ^^^^^^^^^^^^^ qdisc pfifo 20: parent 1:2 limit 1000p Sent 85357120 bytes 59298 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 50470b 35p requeues 0 ^^^^^^^^^^^^^^^^^^ qdisc pfifo 30: parent 1:3 limit 1000p Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 ^^^^^^^^^^^^^ > I have tried to configure PQ to have two queues per filter with no success. What do you mean? > Is it even possible to have (what I'll call) hierarchical PQ? I have yet to > find it. Something like this? tc qdisc add dev eth1 handle 1: root prio tc qdisc add dev eth1 parent 1:1 handle 10 prio tc qdisc add dev eth1 parent 1:2 handle 20 prio tc qdisc add dev eth1 parent 1:3 handle 30 prio Regards /Christian [ http://benve.info ] ------------------------------ Message: 3 Date: Fri, 15 Jun 2007 15:46:31 +0800 From: "Salim S I" <salim.si@xxxxxxxxxxxxxxxx> Subject: RE: Re: PQ questions To: "'Christian Benvenuti'" <christian.benvenuti@xxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Message-ID: <001801c7af21$4d9a5510$5964a8c0@SalimSi> Content-Type: text/plain; charset="us-ascii" Slightly offtopic... Has anyone really experienced starving of low priority traffic with PRIO qdisc? In my setup, I never achieved that, though I also wanted exactly that situation. I gave both the classes same amount of traffic at the same time. High prio got more bandwidth, but no starvation, even after I sent more traffic than the link capacity. > -----Original Message----- > From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > On Behalf Of Christian Benvenuti > Sent: Friday, June 15, 2007 3:32 PM > To: lartc@xxxxxxxxxxxxxxx > Subject: Re: PQ questions > > Hi, > > > > Your config does not prevent an higher priority class from starving > > > a lower priority class. > > > > Exactly. That is requirement. > > OK > > > Those stats are nice to have, but the ones I must have are for how many > > bytes/packets are enqueued at whatever time I check the queues. > > That information is there. Here is an example: > (b=bytes p=packets) > > #tc -s -d qdisc list dev eth1 > > qdisc prio 1: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > Sent 85357186 bytes 59299 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 35p requeues 0 > +-> This field is not initialized for this > qdisc type > qdisc pfifo 10: parent 1:1 limit 1000p > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > ^^^^^^^^^^^^^ > qdisc pfifo 20: parent 1:2 limit 1000p > Sent 85357120 bytes 59298 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 50470b 35p requeues 0 > ^^^^^^^^^^^^^^^^^^ > qdisc pfifo 30: parent 1:3 limit 1000p > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > rate 0bit 0pps backlog 0b 0p requeues 0 > ^^^^^^^^^^^^^ > > > I have tried to configure PQ to have two queues per filter with no > success. > > What do you mean? > > > Is it even possible to have (what I'll call) hierarchical PQ? I have yet > to > > find it. > > Something like this? > > tc qdisc add dev eth1 handle 1: root prio > tc qdisc add dev eth1 parent 1:1 handle 10 prio > tc qdisc add dev eth1 parent 1:2 handle 20 prio > tc qdisc add dev eth1 parent 1:3 handle 30 prio > > Regards > /Christian > [ http://benve.info ] > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ------------------------------ Message: 4 Date: Fri, 15 Jun 2007 10:16:12 +0200 From: Christian Benvenuti <christian.benvenuti@xxxxxxxxx> Subject: Re: PQ questions To: lartc@xxxxxxxxxxxxxxx Message-ID: <1181895372.2702.20.camel@benve-laptop> Content-Type: text/plain Hi, a class is starved only if those with higher priority are always (of pretty often) backlogged and do not give the lower priority classes a chance to transmit. Therefore, if you transmit at a rate smaller than your CPU/s and NIC/s can handle you will not experience any starving. For example, if you generate 50Mbit traffic on a 100Mbit NIC it is likely that you won't see any starving (unless your system is not able to handle 50Mbit traffic because of a complex TC or iptables configuration that consumes lot of CPU). Regards /Christian [ http://benve.info ] On Fri, 2007-06-15 at 15:46 +0800, Salim S I wrote: > Slightly offtopic... Has anyone really experienced starving of low > priority traffic with PRIO qdisc? > In my setup, I never achieved that, though I also wanted exactly that > situation. I gave both the classes same amount of traffic at the same > time. High prio got more bandwidth, but no starvation, even after I sent > more traffic than the link capacity. > > > -----Original Message----- > > From: lartc-bounces@xxxxxxxxxxxxxxx > [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > > On Behalf Of Christian Benvenuti > > Sent: Friday, June 15, 2007 3:32 PM > > To: lartc@xxxxxxxxxxxxxxx > > Subject: Re: PQ questions > > > > Hi, > > > > > > Your config does not prevent an higher priority class from > starving > > > > a lower priority class. > > > > > > Exactly. That is requirement. > > > > OK > > > > > Those stats are nice to have, but the ones I must have are for how > many > > > bytes/packets are enqueued at whatever time I check the queues. > > > > That information is there. Here is an example: > > (b=bytes p=packets) > > > > #tc -s -d qdisc list dev eth1 > > > > qdisc prio 1: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > > Sent 85357186 bytes 59299 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 35p requeues 0 > > +-> This field is not initialized for this > > qdisc type > > qdisc pfifo 10: parent 1:1 limit 1000p > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > ^^^^^^^^^^^^^ > > qdisc pfifo 20: parent 1:2 limit 1000p > > Sent 85357120 bytes 59298 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 50470b 35p requeues 0 > > ^^^^^^^^^^^^^^^^^^ > > qdisc pfifo 30: parent 1:3 limit 1000p > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > rate 0bit 0pps backlog 0b 0p requeues 0 > > ^^^^^^^^^^^^^ > > > > > I have tried to configure PQ to have two queues per filter with no > > success. > > > > What do you mean? > > > > > Is it even possible to have (what I'll call) hierarchical PQ? I have > yet > > to > > > find it. > > > > Something like this? > > > > tc qdisc add dev eth1 handle 1: root prio > > tc qdisc add dev eth1 parent 1:1 handle 10 prio > > tc qdisc add dev eth1 parent 1:2 handle 20 prio > > tc qdisc add dev eth1 parent 1:3 handle 30 prio > > > > Regards > > /Christian > > [ http://benve.info ] ------------------------------ Message: 5 Date: Fri, 15 Jun 2007 17:13:48 +0800 From: "Salim S I" <salim.si@xxxxxxxxxxxxxxxx> Subject: RE: Re: PQ questions To: "'Christian Benvenuti'" <christian.benvenuti@xxxxxxxxx>, <lartc@xxxxxxxxxxxxxxx> Message-ID: <001901c7af2d$7c6e21d0$5964a8c0@SalimSi> Content-Type: text/plain; charset="us-ascii" I tested on wireless link. It could give a maximum of 45Mbps. And I sent 30Mbps of both low prio and high prio traffic. Total of 60Mbps. My test was done with UDP, using tcpdump. When I increased the bandwidth to 40Mbps each, the high priority class got lesser bandwidth. (maybe the effect of the known issue that large amount of low prio traffic can starve high prio traffic) > -----Original Message----- > From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > On Behalf Of Christian Benvenuti > Sent: Friday, June 15, 2007 4:16 PM > To: lartc@xxxxxxxxxxxxxxx > Subject: Re: PQ questions > > Hi, > a class is starved only if those with higher priority are > always (of pretty often) backlogged and do not give the lower > priority classes a chance to transmit. > Therefore, if you transmit at a rate smaller than your CPU/s and > NIC/s can handle you will not experience any starving. > > For example, if you generate 50Mbit traffic on a 100Mbit NIC > it is likely that you won't see any starving (unless your system is > not able to handle 50Mbit traffic because of a complex TC or > iptables configuration that consumes lot of CPU). > > Regards > /Christian > [ http://benve.info ] > > On Fri, 2007-06-15 at 15:46 +0800, Salim S I wrote: > > Slightly offtopic... Has anyone really experienced starving of low > > priority traffic with PRIO qdisc? > > In my setup, I never achieved that, though I also wanted exactly that > > situation. I gave both the classes same amount of traffic at the same > > time. High prio got more bandwidth, but no starvation, even after I sent > > more traffic than the link capacity. > > > > > -----Original Message----- > > > From: lartc-bounces@xxxxxxxxxxxxxxx > > [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > > > On Behalf Of Christian Benvenuti > > > Sent: Friday, June 15, 2007 3:32 PM > > > To: lartc@xxxxxxxxxxxxxxx > > > Subject: Re: PQ questions > > > > > > Hi, > > > > > > > > Your config does not prevent an higher priority class from > > starving > > > > > a lower priority class. > > > > > > > > Exactly. That is requirement. > > > > > > OK > > > > > > > Those stats are nice to have, but the ones I must have are for how > > many > > > > bytes/packets are enqueued at whatever time I check the queues. > > > > > > That information is there. Here is an example: > > > (b=bytes p=packets) > > > > > > #tc -s -d qdisc list dev eth1 > > > > > > qdisc prio 1: root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 > > > Sent 85357186 bytes 59299 pkt (dropped 0, overlimits 0 requeues 0) > > > rate 0bit 0pps backlog 0b 35p requeues 0 > > > +-> This field is not initialized for this > > > qdisc type > > > qdisc pfifo 10: parent 1:1 limit 1000p > > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > > rate 0bit 0pps backlog 0b 0p requeues 0 > > > ^^^^^^^^^^^^^ > > > qdisc pfifo 20: parent 1:2 limit 1000p > > > Sent 85357120 bytes 59298 pkt (dropped 0, overlimits 0 requeues 0) > > > rate 0bit 0pps backlog 50470b 35p requeues 0 > > > ^^^^^^^^^^^^^^^^^^ > > > qdisc pfifo 30: parent 1:3 limit 1000p > > > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > > > rate 0bit 0pps backlog 0b 0p requeues 0 > > > ^^^^^^^^^^^^^ > > > > > > > I have tried to configure PQ to have two queues per filter with no > > > success. > > > > > > What do you mean? > > > > > > > Is it even possible to have (what I'll call) hierarchical PQ? I have > > yet > > > to > > > > find it. > > > > > > Something like this? > > > > > > tc qdisc add dev eth1 handle 1: root prio > > > tc qdisc add dev eth1 parent 1:1 handle 10 prio > > > tc qdisc add dev eth1 parent 1:2 handle 20 prio > > > tc qdisc add dev eth1 parent 1:3 handle 30 prio > > > > > > Regards > > > /Christian > > > [ http://benve.info ] > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc ------------------------------ Message: 6 Date: Fri, 15 Jun 2007 17:36:20 +0800 From: "Salim S I" <salim.si@xxxxxxxxxxxxxxxx> Subject: RE: Re: multiple routing tables for internal router programs To: "'Peter Rabbitson'" <rabbit@xxxxxxxxx> Cc: lartc@xxxxxxxxxxxxxxx Message-ID: <001a01c7af30$a4c23330$5964a8c0@SalimSi> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: lartc-bounces@xxxxxxxxxxxxxxx [mailto:lartc-bounces@xxxxxxxxxxxxxxx] > On Behalf Of Peter Rabbitson > Sent: Friday, June 15, 2007 2:30 PM > Cc: lartc@xxxxxxxxxxxxxxx > Subject: Re: Re: multiple routing tables for internal router > programs > Well then you are certainly ahead of the game. Still I would suggest to > avoid the complexity of bit mask marks - it is rather error prone and is > pretty hard to maintain, while the same result can usually be achieved > by other means (like in my SNAT example). As far as your original > problem goes - it seems like a mark is getting eaten away or is not set > somewhere in the first place. I have not had any problems like the ones > you describe. Those different MARKs are used for policy-routing, load balancing, firewall, traffic control, virtual server, user-group profiles etc. I think eventually you may have to use it, warts and all, or find some other way for integrating all those. :-) I will soon run out of bits, it seems. I've replaced that multipath rule for local packets with a single route, and change it on failovers. No balancing for local traffic, but there isn't much local traffic anyway. ------------------------------ _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc End of LARTC Digest, Vol 28, Issue 23 ************************************* -------------------------------------------------------------------- mail2web LIVE ? Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
