[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ack and priq



On Thu, Nov 20, 2003 at 02:44:54PM +0100, Robert Winder wrote:
> * Must the connection be saturated at 100% before priq scheduling can
> kick in.
Yes, if you see no (or just little) packets dropped by the queues, there
is no effect. Basically, dropping is the only effect queueing has in
this case (ignoring send queue order, someone correct me if that's
oversimplifying ;).
queue q_pri priority 7 
  [ pkts:      93191  bytes:  5053870  dropped pkts:   0 bytes: 0 ]
  [ qlength:   0/ 50 ]
queue q_def priq( default ) 
  [ pkts:      11753  bytes: 12399926  dropped pkts:  31 bytes: 22702 ]
  [ qlength:   0/ 50 ]
Only 31 out of 11753 + 93191 packets were dropped. Hence, the effect of
queueing was unnoticable.
Try lowering the bandwidth limit
  altq on $if_ext priq bandwidth 128Kb queue { q_pri, q_def }
from 128 to 100-75, until you see a significant percentage of dropped
packets in pfctl -vsq. If you set it to 50% of your uplink capacity, you
_have_ to see drops, otherwise something is really wrong.
> * Is option ALTQ base in kernel enough ( last time i checked and that
> was nearly a year ago and additional options where needed to enable PRIQ)
A GENERIC kernel is already sufficient. If you are running a custom
kernel, retry with GENERIC first.
> * Is a pass in rule with priq queueing definitions a requirement
When a state is created last matching a pass rule without queue
assigments, all packets of that state (including empty ACKs) will go to
the default queue. So, yes, if you want outgoing empty ACKs related to
incoming connections to be prioritized, you'll need queue assignments in
the relevant 'pass in ... keep state' rule.
> * Could it be that NAT or the option random_id in scrub rules
> prevents priq sheduling.
Queue assigment doesn't seem to be the problem, you get plenty of
packets assigned to q_pri. And if assignment works, nothing else in pf
could prevent scheduling from working, afaik.
The fact that the queues are not dropping significant numbers of packets
during saturation is the problem. Here's the pfctl -vsq output from my
machine
queue q_max priority 7 
  [ pkts:     476181  bytes:   46935790  dropped pkts:     24 bytes: 5280 ]
  [ qlength:   1/ 50 ]
queue q_low priq( default ) 
  [ pkts:   10803740  bytes: 4535488842  dropped pkts: 870770 bytes: 270465431 ]
  [ qlength:  46/ 50 ]
During times where the queueing has any effect (stops download rates
from dropping due to uplink saturation), I see packets getting dropped
in q_low in significant numbers. Only when the uplink is not saturated
(and the queueing has no noticable effect) I see no increase in dropped
packets.
Daniel