I wanted to see where from a slot the packets got dropped when the queue was full. (e)sfq drops from the longest slot to make space for an incoming packet, so it's not tail drop as such, but the results show me it does drop from the tail of the slot - which if you are trying to shape inbound, is a PITA as tcp "slow" start grows exponentially and overflows into my ISP/telecos buffer, causing a latency bump. I think it would be alot nicer if It head dropped to make the sender go into congestion control quicker.
However this is not the reason for this post. I tested by capturing with tcpdump before and after the queue.
I noticed that the packets were being released in pairs, which probably doesn't help either.
I assume it is htb that calls esfq to dequeue a packet - but I don't know.
For the test my DWIFLIMIT bandwidth was set at 51kbit/s which is 10% of my bandwidth.
My mtu is set at 1478 as it's slightly more efficient for adsl using pppoa/vcmux in the UK.
I used -
$TC class add dev $DWIF parent 1:2 classid 1:21 htb rate $[$DWIFLIMIT/2]kbit \
ceil ${DWIFLIMIT}kbit burst 0b cburst 0b mtu 1478 quantum 1478 prio 1
$TC qdisc add dev $DWIF parent 1:21 handle 21: esfq perturb 0 hash classic limit 10
This is part of tc -s -d class show dev imq1
class htb 1:21 parent 1:2 leaf 21: prio 1 quantum 1478 rate 25Kbit ceil 51Kbit burst 1507b/8 mpu 0b cburst 1540b/8 mpu 0b level 0
Is there anything obvious here that would cause the packets to dequeue in pairs.
TIA
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
