On Tue, 12 Jan 2016 16:40:58 +0100 Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
> 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. > Have we come to conclusion that currently prio makes no sense at all? Can I hope that saying 'currently' means this is not the intended design? Or should I come to peace with the fact that with OpenBSD and PF I can forget about shaping inbound TCP traffic in a way that child queues can expand to max link bandwidth unless there is a congestion, while in congestion admin can choose which child queues to throttle and in which order? -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
