> > Did you add the "linklayer atm" yourself to Dave's script? Well, partly the option for HTB was already in his script but under tested, I changed the script to add stab and to allow easier configuration of overhead, mow, mtu and tsize (just for stab) from the guy, but the code is Dave's. I attached the scripts. functions.sh gets the values from the configuration GUI. I extended the way the linklayer option strings are created, but basically it is the same method that dave used. And I do see the right overhead values appear in "tc -d qdisc", so at least something is reaching HTB. Sorry, that I have no repository for easier access. > > > > >>> >>>>> Now, I have been testing this using Dave's most recent cerowrt >>>>> alpha version with a 3.10.9 kernel on mips hardware, I think this kernel >>>>> should contain all htb fixes including commit 8a8e3d84b17 (net_sched: >>>>> restore "linklayer atm" handling) but am not fully sure. >>>>> >>>> >>>> It does. >>> >>> It have not hit the stable tree yet, but DaveM promised he would pass it along. >>> >>> It does seem Dave Taht have my patch applied: >>> http://snapon.lab.bufferbloat.net/~cero2/patches/3.10.9-1/685-net_sched-restore-linklayer-atm-handling.patch >> >> Ah, good so it should have worked. > > It should... > > >>> >>>>> While I am not able to build kernels, it seems that I am able to quickly >>>>> test whether link layer adjustments work or not. SO aim happy to help where >>>>> I can :) >>> >>> So, what is you setup lab, that allow you to test this quickly? >> >> Oh, Dave and Toke are the giants on whose shoulders I stand here (thanks guys), all I bring to the table basically is the fact that I have an ATM carried ADSL2+ connection at home. > > I will soon have a ADSL lab again, so I try and reproduce your results. > Actually, almost while typing this email, the postman arrived at my > house and delivered a new ADSL modem... as a local Danish ISP > www.fullrate.dk have been so kind to give me a testline for free > (thanks fullrate!). This is great! Even though I am quite sure that no real DSL link is actually required to test the effect of the link layer adjustments. > > >> Anyway, my theory is that proper link layer adjustments should only show up if not performing these would make my traffic exceed my link-speed and hence accumulate in the DSL modems bloated buffers leading to measurable increases in latency. So I try to saturate the both up- and down-link while measuring latency und different conditions. SInce the worst case overhead of the ATM encapsulation approaches 50% (with best case being around 10%) I try to test the system while shaping to 95% percent of link rates where do expect to see an effect of the link layer adjustments and while shaping to 50% where do not expect to see an effect. And basically that seems to work. > >> Practically, I use Toke's netsurf-wrapper project with the RRUL test from my cerowrt router behind an ADSL2+ modem to a close netperf server in Germany. The link layer adjustments are configured in my cerowrt router, using Dave's simple.qos script (3 band HTB shaper with fq_codel on each leaf, taking my overhead of 40 bytes into account and optionally the link layer). > >> It turns out that this test nicely saturates my link with 4 up >> and 4 down TCP flows ad uses a train ping probes at 0.2 second period >> to assess the latency induced by saturating the links. Now I shape down >> to 95% and 50% of line rates and simply look at the ping RTT plot for >> different conditions. In my rig I see around 30ms ping RTT without >> load, 80ms with full saturation and no linklayer adjustments, and 40ms >> with working link layer adjustments (hand in hand with slightly reduced >> TCP good put just as one would expect). In my testing so far activating >> the HTB link layer adjustments yielded the same 80ms delay I get >> without link layer adjustments. If I shape down to 50% of link rates >> HTB, stab and no link layer adjustments yield a ping RTT of ~40ms. >> Still with proper link layer adjustments the TCP good-put is reduced >> even at 50% shaping. As Dave explained with an unloaded swallow ermm, >> ping RTT and fq_codel's target set to 5ms the best case would be 30ms + >> 2*5ms or 40ms, so I am pretty close to ideal with proper link layer >> adjustments. >> > >> I guess it should be possible to simply use the reduction in good-put as an easy indicator whether the link layer adjustments work or not. But to do this properly I would need to be able to control the size of the sent packets which I am not, at least not with RRUL. But I am quite sure real computer scientists could easily set something up to test the good-put through a shaping device at differently sized packet streams of the same bandwidth, but I digress. >> >> On the other hand I do not claim to be an expert in this field in any way and my measurement method might be flawed, if you think so please do not hesitate to let me know how I could improve it. > > I have a hard time following your description... sorry. Okay, I see, let me try to present the data in a more ordered fashion: BW: bandwidth [Kbit/s] LLAM = link-layer adjustment method LL: link layer GP: goodput [Kbit/s] # shaped downBW (%) upBW (%) LLAM LL ping RTT downGP upGP 1 no 16309 100 2544 100 none none 300ms 10000 1600 2 yes 14698 90 2430 95 none none 80ms 13600 1800 3 yes 14698 90 2430 95 stab adsl 40ms 11600 1600 4 yes 15494 95 2430 95 stab adsl 42ms 12400 1600 5 yes 14698 90 2430 95 htb adsl 75ms 13200 1600 2 yes 7349 45 1215 48 none none 45ms 6800 1000 4 yes 7349 45 1215 48 stab adsl 42ms 5800 800 5 yes 7349 45 1215 48 htb adsl 45ms 6600 1000 Notes: upGP is way noisier than downGP and therefore harder to estimate So condition# 3 and 4 show the best latency at high link saturation where link layer adjustments actually make a difference, by controlling whether the DSL modem will buffer or not At ~50% link saturation there is not much, if any effect of the link layer adjustments on latency, but it still leaves its hallmark on good put reduction. (The partial reduction for htb might be caused by the specification of 40 bytes of overhead which seem to have been honored). I take the disappearance of the latency effect at 50% as a control data point that shows my measurement approach seems sane enough. I hope this clears up the information I wanted to give you the first time around. > > So, did you get a working-low-latency setup by using 95% shaping and > "stab" linklayer adjustment? Yes. (With a 3 leaf HTB as shaper and fq_codel as disc) Best Regards Sebastian > > -- > Best regards, > Jesper Dangaard Brouer > MSc.CS, Sr. Network Kernel Developer at Red Hat > Author of http://www.iptv-analyzer.org > LinkedIn: http://www.linkedin.com/in/brouer