On Tue, Jan 12, 2016 at 05:33:06AM -0700, Daniel Melameth wrote: > On Mon, Jan 11, 2016 at 9:37 PM, David Gwynne <da...@gwynne.id.au> wrote: > >> On 11 Jan 2016, at 22:43, Daniel Melameth <dan...@melameth.com> wrote: > >> On Sun, Jan 10, 2016 at 7:58 AM, Marko Cupa?? <marko.cu...@mimar.rs> > wrote: > >>> On Sat, 9 Jan 2016 11:11:27 -0700 > >>> Daniel Melameth <dan...@melameth.com> wrote: > >>>> You NEED to set a max on your ROOT queues. > >>> I came to this conclusion as well. But not only on root queues. For > >>> example, when max is set on root queue but only bandwidth on child > >>> queues, no shaping takes place... > >> This works for me. > >>> Or, to cut the long story short, if someone can paste queue definition > >>> which accomplishes 'give both queues max bandwidth, but throttle > >>> traffic from first queue when traffic from the second one arrives', I > >>> will be more than happy to quit bothering misc@ list readers with my > >>> rants and observations. > >> I would expect this to be possible with prio alone, but I've never > >> been able to get it to work. Perhaps I'm misunderstanding how prio > >> works. > > prio is basically an array of lists of packets to be transmitted. high > priority packets go on a different list to low priority packets. > > > > the problem is the way packets go on and off these lists. basically as soon > as a packet is queued on one of these lists for transmission, we call the > driver immediately to send it. generally as soon as a packet is queued on the > interface, it immediately gets dequeued by the driver and transmitted on the > hardware. > > > > it is only when you build up a backlog of packets that priq can come into > effect. the only way you can build up a backlog of packets is if your hardware > is slower at transmitting packets than the thing that generates these packets > to send. > > > > in your case you're probably getting packets from a relatively slow internet > connection and transmitting them on a high speed local network. the transmit > hardware is almost certainly going to be faster than your source of packets, > so you'll never build up a queue of backlogged packets, so prio is effectively > a nop. > > > > dlg > > Thanks for taking the time to chime in guys. Prior to implementing > any queueing, I tested this stuff out on a LAN--so no slower > connectionswere involved--and I was unable to see prio in action, at > least not with any observable similarity to ALTQ's PRIQ. > > A simple rule set: > > match out on egress proto tcp to port 12345 set prio 7 > match out on egress proto tcp to port 12346 set prio 0 > pass > > Using tcpbench to push packets into both queues, I would have expected > the packets destined for port 12346 to get throttled, but both flows > simply reached an equilibrium, which I would have expected without > prio. Under PRIQ, I would have seen the flow to port 12346 get almost > completely starved of bandwidth. When doing non-prio queuing with a > similarly simple ruleset, both flows properly matched their target > bandwidth.
This assumes that you manage to fill the TX interface queue to a level that it always fills the tx DMA rings before being empty. On high speed interfaces this most of the time not the case and so both sessions are able to reach the maximum bandwidth. To be honest prio queue only make sense when you have a slow interface (10Mbps) or a shaper in place that causes the queue to fill up. There is currently no shaper you can use together with the prio queues so only option one remains. -- :wq Claudio
