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.
