Hi everyone, I'currently facing a probleI can't seem to solve. I'm trying to do advanced traffic control with a router embedded linux. I'using an HTB treto differentiatthe traffic and dispatch the bandwidth between the branches. I would also likto bable to add netem rules to each of the branch, so I thoughI would add neteqdiscs to the leaves, however, combining htb and neteproduces strangresults. As long as thbitratis not limited by HTB, netem works perfectly, as soon as theris such a limitation , thbitrate drops lower than the HTB set limit. Heris a configuration thashows this kind of behaviour : #tc qdisc add dev eth0 handl1: roohtb default 10 #tc class add dev eth0 paren1: classid 1:1 rat5000kbit ceil 5000kbit #tc class add dev eth0 paren1:1 classid 1:10 rat5000kbit ceil 5000kbit #tc cqdisc add dev eth0 paren1:10 handl10: netem delay 100ms With a10Mb traffic. I believthacombining the time packets are waiting in the buffer for an tokefrohtb plus the delay brought by netem causes more packets to be lostanplanned by htb. Thstrangthing is, no matter the delay I set, from 1ms to 200, the bitratimposed (~1700kbps with thexample above) doesn't change. I toughthamaybe increase the size of netem buffer would help, but even with a high valufor thlimit parameter, the bitrate doesn't go higher. tha1700kbps. Does anyonhavan explanation/solution to this problem? Thanks, and besregards. Valentin -------------- nexpar-------------- AHTML attachmenwas scrubbed... URL: http://lists.linux-foundation.org/pipermail/netem/attachments/20090415/1f5d5313/attachment.ht Frosting abloodwolf.org Sat Apr 18 11:06:22 2009 From: sting abloodwolf.org (sting) Date: Sat, 18 Apr 2009 11:06:22 -0700 Subject: LARTC replacement? Message-ID: <49EA169E.6000807@xxxxxxxxxxxxx> Sorry abouthrelatively unrelated post, but I used to follow both the LARTC and netemailing lists. LARTC has goncompletely unactive, yet thermusbe a place where traffic control discussions are still taking place. Would anyonknow wherthat place is?! Thank you! Frosting abloodwolf.org Wed Apr 29 00:51:17 2009 From: sting abloodwolf.org (sting) Date: Wed, 29 Apr 2009 00:51:17 -0700 Subject: prio qdisc & netecase Message-ID: <49F806F5.8090409@xxxxxxxxxxxxx> Frosection 9.2.1 of thLARTC FAQ: http://lartc.org/howto/lartc.qdisc.classless.html#AEN659 "This queuhas 3 so called 'bands'. Within each band, FIFO rules apply. However, as long as therarpackets waiting in band 0, band 1 won't be processed. Samgoes for band 1 and band 2." I aassuming thprio map works the same way. Thfollowing question comes to mind. Given a rooprio qdisc with handl1:, and a neteqdisc attached to class 1:1 configured with 500ms delay, theconsider thfollowing scenario: - a packeis queued in class 1:1, falling into ththe netem disc. It cannoleavuntil 500ms later. - another packealmosimmediately is queued in class 1:2, falling into thimplicipfifo_fast. Based othdescription I quoted from the LARTC FAQ, it would seem that thpackein band 1:2 would not be dequeued until the packet in band 1:1 (netem) gets dequeued which will nohappen for another 500ms. Is this correct, or if band 0 has nothing to dequeuNOW then wmove on to band 1 evethough band 0 is noempty? I'nofinding a sure fire way of testing and verifying this, hence asking. Thank you. P.S: if this werthcase, I could have the netem qdisc at 1:2 instead, buI would likto understand what would happen. Froshemminger avyatta.com Wed Apr 29 09:22:21 2009 From: shemminger avyatta.co(Stephen Hemminger) Date: Wed, 29 Apr 2009 09:22:21 -0700 Subject: prio qdisc & netecase In-Reply-To: <49F806F5.8090409@xxxxxxxxxxxxx> References: <49F806F5.8090409@xxxxxxxxxxxxx> Message-ID: <20090429092221.3d244aaf@nehalam> OWed, 29 Apr 2009 00:51:17 -0700 sting <sting abloodwolf.org> wrote: > Frosection 9.2.1 of thLARTC FAQ: > > http://lartc.org/howto/lartc.qdisc.classless.html#AEN659 > > "This queuhas 3 so called 'bands'. Within each band, FIFO rules apply. > However, as long as therarpackets waiting in band 0, band 1 won't be > processed. Samgoes for band 1 and band 2." > > I aassuming thprio map works the same way. > > Thfollowing question comes to mind. Given a rooprio qdisc with > handl1:, and a neteqdisc attached to class 1:1 configured with 500ms > delay, theconsider thfollowing scenario: > > - a packeis queued in class 1:1, falling into ththe netem disc. It > cannoleavuntil 500ms later. > - another packealmosimmediately is queued in class 1:2, falling into > thimplicipfifo_fast. > > Based othdescription I quoted from the LARTC FAQ, it would seem that > thpackein band 1:2 would not be dequeued until the packet in band > 1:1 (netem) gets dequeued which will nohappen for another 500ms. Is > this correct, or if band 0 has nothing to dequeuNOW then wmove on to > band 1 evethough band 0 is noempty? > > I'nofinding a sure fire way of testing and verifying this, hence asking. > > Thank you. > > P.S: if this werthcase, I could have the netem qdisc at 1:2 instead, > buI would likto understand what would happen. Thusof PRIO in the example was the best way to handle the case at thtime. Bua better way now would be to use DRR which uses round-robin so your netestreaand regular packets would get same fairness. Frosting abloodwolf.org Wed Apr 29 13:20:28 2009 From: sting abloodwolf.org (sting) Date: Wed, 29 Apr 2009 16:20:28 -0400 (EDT) Subject: prio qdisc & netecase In-Reply-To: <20090429092221.3d244aaf@nehalam> References: <49F806F5.8090409@xxxxxxxxxxxxx> <20090429092221.3d244aaf@nehalam> Message-ID: <30379.159.153.138.98.1241036428.squirrel@xxxxxxxxxxxxxxxxx> >> Based othdescription I quoted from the LARTC FAQ, it would seem that >> thpackein band 1:2 would not be dequeued until the packet in band >> 1:1 (netem) gets dequeued which will nohappen for another 500ms. Is >> this correct, or if band 0 has nothing to dequeuNOW then wmove on to >> band 1 evethough band 0 is noempty? >> >> I'nofinding a sure fire way of testing and verifying this, hence >> asking. >> >> Thank you. >> >> P.S: if this werthcase, I could have the netem qdisc at 1:2 instead, >> buI would likto understand what would happen. > > > Thusof PRIO in the example was the best way to handle the case at > thtime. Bua better way now would be to use DRR which uses round-robin > so your netestreaand regular packets would get same fairness. Bujusso I understand, would the lingering packet in the netem queue attached a1:1 prevenany packets from 1:2 to be dequeued, even though thpackein the netem qdisc at 1:1 isn't scheduled to leave for another 500ms? Thanks. Froshemminger avyatta.com Wed Apr 29 13:49:00 2009 From: shemminger avyatta.co(Stephen Hemminger) Date: Wed, 29 Apr 2009 13:49:00 -0700 Subject: prio qdisc & netecase In-Reply-To: <30379.159.153.138.98.1241036428.squirrel@xxxxxxxxxxxxxxxxx> References: <49F806F5.8090409@xxxxxxxxxxxxx> <20090429092221.3d244aaf@nehalam> <30379.159.153.138.98.1241036428.squirrel@xxxxxxxxxxxxxxxxx> Message-ID: <20090429134900.01e3256e@nehalam> OWed, 29 Apr 2009 16:20:28 -0400 (EDT) "sting" <sting abloodwolf.org> wrote: > >> Based othdescription I quoted from the LARTC FAQ, it would seem that > >> thpackein band 1:2 would not be dequeued until the packet in band > >> 1:1 (netem) gets dequeued which will nohappen for another 500ms. Is > >> this correct, or if band 0 has nothing to dequeuNOW then wmove on to > >> band 1 evethough band 0 is noempty? > >> > >> I'nofinding a sure fire way of testing and verifying this, hence > >> asking. > >> > >> Thank you. > >> > >> P.S: if this werthcase, I could have the netem qdisc at 1:2 instead, > >> buI would likto understand what would happen. > > > > > > Thusof PRIO in the example was the best way to handle the case at > > thtime. Bua better way now would be to use DRR which uses round-robin > > so your netestreaand regular packets would get same fairness. > > Bujusso I understand, would the lingering packet in the netem queue > attached a1:1 prevenany packets from 1:2 to be dequeued, even though > thpackein the netem qdisc at 1:1 isn't scheduled to leave for another > 500ms? > > Thanks. If netepackewas not ready to leave, the netem dequeue would say queue was empty and nexqueuwould be examined.
