From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id A0F463BA8D; Tue, 31 Jan 2017 11:40:02 -0500 (EST) Received: by mail-wj0-x242.google.com with SMTP id kq3so11373963wjc.3; Tue, 31 Jan 2017 08:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=X2hwjqNkDKBSCW/xcYldjHjLOMtWdlBkUQPdJfHqX2Y=; b=KS7Bayon6ZvdFIf/orcENY90npU3QqzandUESkhsNhPFkWNXSbdepg8m1r7NLL9rvQ FZ5TRScXhvN0TQgfXXCEyPMGhsTohFZqtu3ebI9cG7N56WSX5sQLp+RS23xjjfRLwmNr vdfggGiAwUtWfDS+pRqrMd5U+OosW2iQHTLz3xS3T9q0gLyYA650F7Wli3/5dee9EBLj Ih2cj0Sj/tLcylQemII1A66NkjPC3tibUgh6eDf/L1Ihvzd5ZyTvnXMj8U2smArZ493G SieyrGzZFYohGn5XerPqhq81s+Uyh7/aw1bZYERgOGtTKG+k9DqAlMIb5esMd/nRK9G1 IPxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=X2hwjqNkDKBSCW/xcYldjHjLOMtWdlBkUQPdJfHqX2Y=; b=IeKcspSVihcSkmPoqPXOKHpe+vIscKddeL8pJUw20ZXvoYi/TElCQk7TKu8S33+JH4 Kxdk70Bls/8MU2P1TLXPJUserW2oYIU3TVM9+NjjI3Rl3aYBK0bn38FQ8n61HAjnKup4 DyHgtrOQUavLSSC2RuoBPf8WoPnhputrvsCWOGws9iDCu9wmLAjRFAfeXAiZGPUg+Fyv 5Kj7kyyJI0cFbYVdQLSlP0V3E7uuo7/iXW8yNrIyDQ1XW0J052M+5JPv6GgEYX4SDhIl Mxt1uAJYNwvRwS1OMlrWJCxN5h0mZha8lqAbWo6B0GVOXaLqNh8BlajBdyuMe8ddMR9P cUPg== X-Gm-Message-State: AIkVDXLxCQ4K5+1yYjCvrII10sc7e62ydl6FuLPa73SU9ORXqKLDkhRVPrMyLPKzGyy++A== X-Received: by 10.223.138.241 with SMTP id z46mr29661699wrz.30.1485880801423; Tue, 31 Jan 2017 08:40:01 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id m29sm29193991wrm.38.2017.01.31.08.40.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 31 Jan 2017 08:40:00 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5FA5FF85-BF67-43E2-AF63-B686B2C65BD7" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Tue, 31 Jan 2017 17:40:02 +0100 Cc: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , cake@lists.bufferbloat.net, make-wifi-fast@lists.bufferbloat.net Message-Id: <0C9BC62D-5317-4D03-9419-FB54EF22DF24@gmail.com> References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> To: Dave Taht X-Mailer: Apple Mail (2.3124) Subject: Re: [Make-wifi-fast] Flent results for point-to-point Wi-Fi on LEDE/OM2P-HS available X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 16:40:02 -0000 --Apple-Mail=_5FA5FF85-BF67-43E2-AF63-B686B2C65BD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 31, 2017, at 12:21 AM, Dave Taht wrote: >=20 > A backstory of how I got involved in the bufferbloat effort was that I > deployed some shiny "new" and "faster" wireless-n radios (6 years > ago)... and my WISP network in Nicaragua collapsed in rain - which was > about 6 months after I'd made the cutover from g and from motorola's > radios. The signal strength was within expected parameters, the > achieved rates were half to 1/3 what they were dry, but latencies > climbed to over 30 seconds in some cases. I had *no* idea what was > going wrong at the time, and it wasn't until 6 months after I closed > the business that I ran into Jim Gettys, and the rest is history. Quite an interesting story, could be in the project background = somewhere. :) > I never got around to writing it up, I just gave a couple talks on the > subject and moved onto fixing bufferbloat thoroughly. We got > distracted by trying to solve it on the ISP backbones before tackling > wifi in this past year. Yeah, I also don=E2=80=99t want to waste too much time trying to improve = latency in their point-to-point Wi-Fi backhaul links unless it=E2=80=99s = going to help. I suppose the questions are: 1) Are their backhaul links stable enough in all conditions to hold a = steady enough rate that soft rate limiting is practical without = sacrificing too much throughput AND 2) Is the sfq setup Ubiquiti has in their gear =E2=80=9Cgood enough=E2=80=9D= in managing bufferbloat that it wouldn=E2=80=99t make much of a = difference anyway. As for the final connection to my residence, it's 3km NLOS through some = deciduous trees close to me, so I have a better signal in winter with no = leaves. While it=E2=80=99s pretty good all things considered (actual 20 = Mbps up, 30 Mbps down when things are well), bitrate can vary maybe 20% = because of the link, and more because of other network load. So even if = fq_codel with soft rate limiting does help, which it does, it=E2=80=99s = not as practical for my final connection to do it. Just thought of it = now, but I wonder if I can run LEDE on my PowerBeam M5-400. Anyway, that=E2=80=99s why I thought backhaul links are a better = candidate for soft rate limiting (since they=E2=80=99re usually = line-of-sight), if it even helps at all (TBD). > ... As for the performance of openmesh being pretty good... they were > the first group to test the fq_codel intermediate queues and ATF code > way back in september, :) - it's not clear to me if that's what you > were testing or not or they shipped an update yet. Just to be clear, I was only testing LEDE on OM2P-HS. I=E2=80=99d like = to test Chaos Calmer (or Open Mesh=E2=80=99s stock firmware), so I=E2=80=99= m not mixing the testing of the ath9k changes with the qdiscs, but = I=E2=80=99ll see if I get to this along with the Ubiquiti testing. > A good test to run is to lower the mcs rates (set the rateset > manually, or add distance, and/or rain) and to see how flat latency > remains. This is also a better test of real-world conditions, if you > can get some reports back on the actual mcs rates being achieved in > the field, and use those. This, I=E2=80=99m definitely going to try. Although I can=E2=80=99t make it rain in my office :) I can use =E2=80=98i= w dev wlan0 set bitrates ht-mcs-2.4 X=E2=80=99, where X is the MCS = level. This appears to be effective, and I could even write a = =E2=80=9Crain.sh" and change it on the fly to see what happens. > It would be my hope that 802.11e is off (rrul will show this, and we > still do badly with it on) 802.11e is on, as it=E2=80=99s the default in LEDE and I didn=E2=80=99t = change it. I can certainly turn that off and compare. > You can probably within this deployment shape the uplinks to some > fairly low value and get good performance more the time. >=20 > I do not have any real hope for being able to make wifi better with > soft-shapers. It's a gordian knot - you need to respond rapidly to > changes in rate, both up and down, and mix up flows thoroughly, > optimize your aggregates to go to one station at a time and switch to > the next, and that's what we got with codel close to the hardware as > it is now in lede. [1] >=20 > If it helps any, this is the best later talk I've given on these = subjects: >=20 > https://www.youtube.com/watch?v=3DRb-UnHDw02o = I understand. Enjoyed that talk thoroughly, thanks! > UBNT's gear (commonly used by wisps) has some neat tricks to manage > things better, when I last took apart their qos system it was an > insane set of sfqs with sf=E2=80=99s. So that was one of my questions, is that setup =E2=80=9Cgood enough=E2=80=9D= that external rate limiting and shaping isn=E2=80=99t worth it, even = with a stable connection. TBD. --Apple-Mail=_5FA5FF85-BF67-43E2-AF63-B686B2C65BD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 31, 2017, at 12:21 AM, Dave Taht <dave.taht@gmail.com>= wrote:

A backstory of how I got involved in the bufferbloat effort = was that I
deployed some shiny "new" and "faster" = wireless-n radios (6 years
ago)... and my WISP network in = Nicaragua collapsed in rain - which was
about 6 months = after I'd made the cutover from g and from motorola's
radios. The signal strength was within expected parameters, = the
achieved rates were half to 1/3 what they were dry, = but latencies
climbed to over 30 seconds in some cases. I = had *no* idea what was
going wrong at the time, and it = wasn't until 6 months after I closed
the business that I = ran into Jim Gettys, and the rest is history.

Quite = an interesting story, could be in the project background somewhere. = :)

I never got around to writing it up, I just = gave a couple talks on the
subject and moved onto fixing = bufferbloat thoroughly. We got
distracted by trying to = solve it on the ISP backbones before tackling
wifi in this = past year.

Yeah, I also don=E2=80=99t want to waste too much = time trying to improve latency in their point-to-point Wi-Fi backhaul = links unless it=E2=80=99s going to help. I suppose the questions = are:

1) Are their backhaul links = stable enough in all conditions to hold a steady enough rate that soft = rate limiting is practical without sacrificing too much throughput = AND
2) Is the sfq setup Ubiquiti has in their gear =E2=80=9Cgood= enough=E2=80=9D in managing bufferbloat that it wouldn=E2=80=99t make = much of a difference anyway.

As for = the final connection to my residence, it's 3km NLOS through some = deciduous trees close to me, so I have a better signal in winter with no = leaves. While it=E2=80=99s pretty good all things considered (actual 20 = Mbps up, 30 Mbps down when things are well), bitrate can vary maybe 20% = because of the link, and more because of other network load. So even if = fq_codel with soft rate limiting does help, which it does, it=E2=80=99s = not as practical for my final connection to do it. Just thought of it = now, but I wonder if I can run LEDE on my PowerBeam = M5-400.

Anyway, that=E2=80=99s why I = thought backhaul links are a better candidate for soft rate limiting = (since they=E2=80=99re usually line-of-sight), if it even helps at all = (TBD).

... As for the performance of = openmesh being pretty good... they were
the first group to = test the fq_codel intermediate queues and ATF code
way = back in september, :) - it's not clear to me if that's what you
were testing or not or they shipped an update yet.

Just = to be clear, I was only testing LEDE on OM2P-HS. I=E2=80=99d like to = test Chaos Calmer (or Open Mesh=E2=80=99s stock firmware), so I=E2=80=99m = not mixing the testing of the ath9k changes with the qdiscs, but I=E2=80=99= ll see if I get to this along with the Ubiquiti testing.

A good test to run is to lower the mcs rates (set the = rateset
manually, or add distance, and/or rain) and to see = how flat latency
remains. This is also a better test of = real-world conditions, if you
can get some reports back on = the actual mcs rates being achieved in
the field, and use = those.

This, I=E2=80=99m definitely going to = try.

Although I can=E2=80=99t make = it rain in my office :) I can use =E2=80=98iw dev wlan0 set bitrates = ht-mcs-2.4 X=E2=80=99, where X is the MCS level. This appears to be = effective, and I could even write a =E2=80=9Crain.sh" and change it on = the fly to see what happens.

It would be my hope that = 802.11e is off (rrul will show this, and we
still do badly = with it on)

802.11e is on, as it=E2=80=99s the default in LEDE and I = didn=E2=80=99t change it. I can certainly turn that off and = compare.

You can probably within this deployment shape = the uplinks to some
fairly low value and get good = performance more the time.

I do not have = any real hope for being able to make wifi better with
soft-shapers. It's a gordian knot - you need to respond = rapidly to
changes in rate, both up and down, and mix up = flows thoroughly,
optimize your aggregates to go to one = station at a time and switch to
the next, and that's what = we got with codel close to the hardware as
it is now in = lede. [1]

If it helps any, this is the best = later talk I've given on these subjects:

https://www.youtube.com/watch?v=3DRb-UnHDw02o

I = understand. Enjoyed that talk thoroughly, thanks!

UBNT's gear (commonly used by wisps) has some neat tricks to = manage
things better, when I last took apart their qos = system it was an
insane set of sfqs with sf=E2=80=99s.

So = that was one of my questions, is that setup =E2=80=9Cgood enough=E2=80=9D = that external rate limiting and shaping isn=E2=80=99t worth it, even = with a stable connection. TBD.

= --Apple-Mail=_5FA5FF85-BF67-43E2-AF63-B686B2C65BD7--