[Cerowrt-devel] uplink_buffer_adjustment

[Dave Taht]

On Tue, Feb 25, 2014 at 7:59 AM, Jim Gettys <jg at freedesktop.org> wrote:
>
>
>
> On Tue, Feb 25, 2014 at 6:14 AM, Oliver Niesner <oliver.niesner at gmail.com>
> wrote:
>>
>> Hi list,
>>
>> I use cerowrt (3.10.24-8) direct behind my main dsl Router.
>> SQM is set and performance is good.
>> When i used Netalyzr from my smartphone i've got good results.
>>
>> > Network buffer measurements (?): Uplink 96 ms, Downlink is good
>>
>> But when i use my notebook i get this:
>>
>> > Network buffer measurements (?): Uplink 1200 ms, Downlink is good
>>
>> I tried even wired connection and set ring buffer rx/tx with ethtool to
>> 64, but
>> only minimal change in uplink buffer (1100ms).
>>
>> Has anyone an idea, what i can try to get better uplink performance?
>
>
> Netalyzr uses a UDP based test for "filling the buffers"; it is not
> responsive to drops/marks at all, the way a TCP test would be.
>
> So if you run it, the flows it generates are unresponsive, and indicate the
> true size of the buffers at the bottleneck link, even though any normal TCP
> would long since have responded and nothing like that amount of buffering
> would have taken place.  Furthermore, the flow queuing of fq_codel isolates
> those flows from other flows, and therefore you do not get the bad latency
> you would otherwise get on those flows.
>
> In short, (particularly since fq_codel is deployed in quantity millions by a
> few ISP's already; it is no longer a fluke to find it only in hacker's
> hands), Nick Weaver needs to improve netalyzr to detect flow queuing
> algorithms and make some sense out of the situation.  It would be great to
> monitor the spread of these algorithms around the Internet over the coming
> years.
>
> So it is arguably a "bug" in netalyzr.  It is certainly extremely
> misleading.

A lot of evidence has accumulated that SFQ and SQF is widely deployed
by more than a few DSL providers, notably several in France have come
forward. There is some evidence it is in some firmwares, too.

SFQ is the default on free.fr's old boxes, and fq_codel was deployed
on their revolution V6 product august 2012 (an upgrade to linux 3.11
with better hashing support for ipv6 and 6rd is on its way).

They were kind enough to document their QoS/AQM/Scheduling system for
me (and point us at problems in setting the fq_codel target too low on
low bandwidth links which we've now fixed in cerowrt's sqm system (but
is not yet fixed in openwrt's qos-scripts or dd-wrts, sigh)), which I
have begun to encapsulate in this still very drafty internet draft:

http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html

So the naive single udp flow packet flooding test in netanalyzer in
speedtest and in netalyzer (and most other tools) gives misleading
results as to the effects of and size of bufferbloat in whole
countries, and I REALLY wish we could get good data on the total size
of the deployment of these technologies worldwide.

Measuring using a high rate flow, simultaneously with a low rate flow
on a different 5 tuple, will show more truth. Preferably
bidirectionally, at the same time....

> Nick?
>
>                                              - Jim
>
>>
>> Regards,
>>
>> Oliver
>>
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html