[LARTC] HTB/SFQ dequeueing in pairs

[Andy Furniss <andy.furniss@dsl.pipex.com>]

I set up a little test to see what the behaviour of (e)sfq was - because 
I couldn't work it out from the source :-) .

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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/