On Tue, 12 Jan 2016 14:37:49 +1000 David Gwynne <da...@gwynne.id.au> wrote:
> 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 > David, Thank you for the explanation of the mechanism. As you say, I am getting packets from a relatively slow internet connection (10M/1M), and transmitting them on a high speed (1G) local network. NICs are 1G. I guess this is standard for majority of smaller deployments (homes, smaller businesses). Besides what you explained now, I don't have the knowledge of underlying queueing mechanisms of PF. But from what you said, it seems logical that it should be possible to build up a queue of backlogged packets not only by hitting physical limit of the hardware, but also by setting logical limit. Otherwise PF prio is only useful to ISPs who can saturate 1G or 10G links. This may sound stupid, but perhaps it would be possible to keep prio values on packets in child queues and let all those queues transfer packets to additional 'outbound' queue before letting driver send it. Something like frame-relay, but not only flagging packets with discard bits and drop them first in cases of congestion, but something more intelligent, which takes into account target, min and max bandwiths, bursts and their timeperiods, priorities... ...which describes the idea of ALTQ HFSC. Which people who know what they are talking say wasn't working. But current queueing mechanism doesn't work for a lot of setups either. Now what? -- Before enlightenment - chop wood, draw water. After enlightenment - chop wood, draw water. Marko Cupać https://www.mimar.rs/
