Re: [Cerowrt-devel] AQM scripts modified for DSL exploration

[Sebastian Moeller <moeller0@gmx.de>]

[-- Attachment #1: Type: text/plain, Size: 3737 bytes --]

Hi Dave,


On Aug 12, 2013, at 02:06 , Dave Taht <dave.taht@gmail.com> wrote:

> Alright I slammed them into ceropackages for the next build but I
> don't get this line:
> 
>        STABSTRING="stab mtu 2048 tsize ${TSIZE} overhead ${OVERHEAD}
> linklayer ${LINKLAYER}"
> 
> mtu 2048?

So it turns out that I got a more complete version ready yesterday. I had a look at the defaults in actual tc and linux kernel code and MTU defaults to 2047 instead of 2048, I guess zero based… Also I am unsure whether the td-stab man page is correct in assuming that the kernel appends the ethernet header size automatically to the packet size (I am a layman but to me it looks like the overhead mechanism just overwrites that information); will try to dig deeper into this...
 I also included the mpu and tsize parameters. Then tested the two implementations with different values put into the fields.
	It looks like stab approach works, at least:

root@nacktmulle:~# tc -d qdisc
qdisc fq_codel a: dev se00 root refcnt 2 limit 1000p flows 1024 quantum 1000 target 5.0ms interval 100.0ms ecn 
qdisc htb 1: dev ge00 root refcnt 2 r2q 10 default 12 direct_packets_stat 0 ver 3.17
 linklayer atm overhead 26 mtu 2047 tsize 128 

but:
tc -d class show dev ge00
class htb 1:11 parent 1:1 leaf 110: prio 1 quantum 1500 rate 128000bit ceil 767000bit burst 1600b/1 mpu 0b overhead 0b cburst 9587b/1 mpu 0b overhead 0b level 0 

So HTB does not report overhead and mpu, no wonder as stab works with a size table and not the rate table that HTB expects, but with the HTB private link layer adaptation mechanism in place I get:

root@nacktmulle:~# tc -d qdisc
qdisc fq_codel a: dev se00 root refcnt 2 limit 1000p flows 1024 quantum 1000 target 5.0ms interval 100.0ms ecn 
qdisc htb 1: dev ge00 root refcnt 2 r2q 10 default 12 direct_packets_stat 0 ver 3.17

which is expected as HTB is not supposed to report anything here, but also:

tc -d class show dev ifb0
class htb 1:11 parent 1:1 leaf 110: prio 1 quantum 1500 rate 32000bit ceil 4899Kbit burst 1600b/1 mpu 0b overhead 0b cburst 244950b/1 mpu 0b overhead 0b level 0 

And Fred Stratton aldso showed (with the ADSL box in AQM ticked):

tc -s -d class show dev ge00
class htb 1:10 parent 1:1 leaf 110: prio 0 quantum 1500 rate 700000bit ceil 700000bit burst 1599b/1 mpu 0b overhead 0b cburst 1599b/1 mpu 0b overhead 0b level 0 

 So it looks like either HTB's private implementation is busted (at least for mpu and overhead). From my searching through the kernel code, my gut feeling is that stab is the preferred method anyway, since it does not fudge with apparent transmit rates (HTB uses a rate table) but instead fudges the packet length to account for the linklayer encapsulation and overhead (it effectively modifies qdisc_skb_cb(skb)->pkt_len)


All this leaves me curious, so I guess I need to figure out a way to test whether the link layer adaptation actually works.
The most visible effect of the ATM quantization is for very small packets were a partly added final atm cell eats a disproportionate part of the bandwidth, so I guess I need to create a stream of such packets and test goodput and latency concurrently. All I need to come up with is the expected goodput at link saturation (with active shaping). This i following the theory that say a 49 byte packet will require two atm cells the second of which is padded with 47 bytes, so almost 50% of the bandwidth is spend for ATM quantization. I guess it might be good to come up with a simple script to test so that it is easier to catch regressions in this functionality more easily. So all I need to do is wrap my head around this and create a simple small script… 

Best
	Sebastian



[-- Attachment #2: usr.zip --]
[-- Type: application/zip, Size: 14857 bytes --]