<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Hi Dave, hi List,<div><br></div><div>to avoid real work I embarked on a (quick) test of my DSL line’s bloat (again). Since I just realized that my ISP has increased my per-packet overhead from 40 bytes to 44 bytes (probably by switching onto a platform that uses VLAN tags between DSL-modem and DSLAM/BRAS, but I digress) my recent netperf-wrapper tests all had been invalidated, since most likely the link layer encapsulation was wrong. So I set out to figure out how close I can shape my DSL line ad still keep decent behavior under load. I used Toke’s great netperf-wrapper (the RRUL test to be precise) against <a href="http://netperf-eu.bufferbloat.net">netperf-eu.bufferbloat.net</a> and tested a number of different up- and downstream shaping values (on an ATM based adsl2+ line with a line rate of 17613Kbps down and 2604 Kbps up, for all tests the proper link layer encapsulation (ATM with overhead 44) has been used) from a macbook attached via the 5GHz radio. </div><div><span class="Apple-tab-span" style="white-space:pre"> </span>The first interesting result is that for my line shaping the upstream to 2000Kbps (76%) actually shows no better ICMP-CDF than shaping to 2575Kbps (98.9%) or even 2604 (100%) independent of the shaping of the downstream. Actually, the slower the uplink gets the larger the average latency gets, just as the upstream target value increases to counter the longer transfer times ("tc -d qdisc” on cerowrt will tell the actual effective target values).</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Downstream shaping results however are more interesting and less clear.</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Attached are three plots of a number of experiments with different downstream-shaping values from 8000 Kbps (8000KU2604K in the legend) up to the line-rate at 17613Kbps (17613KU2604K) to no shaping (0KU0K, that is SQM configured with 0 for up- and downstream). It is quite obvious that no shaping has the highest good-put but at a terrible latency cost (and the DSL-modem is not terribly over-buffered with 85% of the ICMP CDF still below 100ms, but several excursions into the >1000ms range). All downstream shaping values at this overview scale show a massive improvement of latency under load.</div><div><br></div><div><img height="414" width="640" apple-width="yes" apple-height="yes" apple-inline="yes" id="0A2975FF-91BA-4238-B14A-CC036D09E077" src="cid:3492AD5F-F440-4605-9AC6-D92E35B1514B@home.lan"></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>The second plot (*ping_box_scaled.png) shows once more that no shaping is bad for latency under load (from left to right UDP BE, UDP BK, ICMP, UDP EF, averages). Also quite obvious, shaping the downstream just to line rate (gray box: 17613, 100%) still does not give too good a result with lots of variability (but way better than no shaping). Decreasing the downstream further improves the averages for all latency probes but relatively mild compared to the no-shaping and 100% line-rate shaping conditions. <span class="Apple-tab-span" style="white-space:pre"> </span>After the tests I converged on 15852 (90%) and 2575 (99%) which on average shows a increase of latency under load of 15ms pretty close to the theoretical expected value of 10ms (5ms codel target in each direction), which given the access via WLAN is quite decent. (Also a wired test afterwards showed an average increase go 11ms close enough to theory to call it a day.)</div><div><img height="414" width="640" apple-width="yes" apple-height="yes" apple-inline="yes" id="C4105A25-85BB-4A72-996B-78516835309F" src="cid:1689C184-909A-4E61-ADEC-9D14A996BE72@home.lan"></div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>I guess the 2 interesting points are: </div><div>1)<span class="Apple-tab-span" style="white-space:pre"> </span>With a non-congested DSLAM, DSL upstream shaping can be pushed to the extreme of 100% of line rate without having to pay a severe price in latency growth under load. (I remember that we had a discussion that DSL-modems should learn fq_codel so we could regain the lost upstream bandwidth; I guess with proper handling of the encapsulation there is no bandwidth left on the table ;) Still it would be so much nicer if all modems would do this by themselves). </div><div>2)<span class="Apple-tab-span" style="white-space:pre"> </span>On the downstream side of shaping, it really seems to be a question of figuring out which trade-off between bandwidth and latency under load one is willing to accept. (And finally note to self, perform future tests with a wired connection until wifi is fast ;) )</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>P.S.: I hope the images are not too large and still readable.</div><div>Best Regards</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Sebastian</div><div><br></div></body></html>