From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 F0C8A3B2A4; Fri, 10 Feb 2017 02:51:46 -0500 (EST) Received: by mail-wr0-x232.google.com with SMTP id i10so101531520wrb.0; Thu, 09 Feb 2017 23:51:46 -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=S5l0VDtauSCjbP4KYIAK/86iKRReCZjzS0bdScPk6bQ=; b=LiDatDvf+gBYKuEA8VAuJH+YZtom1YbZ89Jp15etZlY2/OqloMU9HNhJBZQRi40y/O oGYu4xs5W4MFE+0FS5/7dJrRHgqmDt1M3ywDiyUeJ2LXHbxhqLzy00PIO6YFFdvlJMNh FqSUIOxz1cPneAIcw7bm0IOKcd51zF6FjRx/6KKlqcUfrl34vaiGL4774aLZHiWPXjIe MBaH2kNtOrn+cQw+Jb9B1PjkbsBusRpu2ugYS9S2IFwrP+/EAhuF3p8WkZx8+4gcceHo OvBgr+ZXDENwnpmmG4Ymk3O4Ve2ZOzGbW6n1YDKhdw/zPXX2tIiSTS0WFvA+HmX/IvoR UcUA== 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=S5l0VDtauSCjbP4KYIAK/86iKRReCZjzS0bdScPk6bQ=; b=UzFDUmtPV39OY8pnAPqMtG+fhY57Y8Rca/n+jvBQvC+IgWWyWlMdkFOjjRLnaeVRDH O2o1evVlFcmhiV0xiARPnTuW1GU3nNEbuWk+SVIGBz6Fkg5pxzgiSFJOiwl/+LHBVFjn CcZdHKlm1aK98OHwopM0M9jIEpxtGcrLAKAkjDecGgl1CEjqGgnpEHWrEBSrqPHcfJUy uajFcK97mfkDTyKQsnT4QeIb55LbSgSQ83jIf/oobF98wa6nCzZKrmLQZ0LJpxaBnUyO N1EqchlfGksO4pFkesMcT9PpuTzQwMdMKvpcEg34dWWsSUbUVroP+pUuT9/9WK8CzR1H 7qBg== X-Gm-Message-State: AMke39mYmCbisaq/aSXJXrFb1cRPO7vQPY7JwWXPak+CnbEieYFxLSE9YvjBuKYBjQwWOg== X-Received: by 10.223.151.205 with SMTP id t13mr6410675wrb.9.1486713105760; Thu, 09 Feb 2017 23:51:45 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id e16sm1357061wra.36.2017.02.09.23.51.44 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 09 Feb 2017 23:51:45 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_21CD7F56-7A38-4AB2-AED2-CF6F869E31D8" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <87r337s9sl.fsf@toke.dk> Date: Fri, 10 Feb 2017 08:51:48 +0100 Cc: make-wifi-fast@lists.bufferbloat.net, cake@lists.bufferbloat.net Message-Id: <4A8C8085-176B-49AD-8D23-3E17A8923652@gmail.com> References: <32C42951-373F-4D90-8936-AA07039E5D73@gmail.com> <877f5c2pew.fsf@toke.dk> <878tpqge5g.fsf@toke.dk> <877f52rz68.fsf@toke.dk> <87bmucu0gs.fsf@toke.dk> <87y3xfsc93.fsf@toke.dk> <5700DFDD-C5C6-482E-A89C-2DB052DA61F0@gmail.com> <87r337s9sl.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= 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: Fri, 10 Feb 2017 07:51:47 -0000 --Apple-Mail=_21CD7F56-7A38-4AB2-AED2-CF6F869E31D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 9, 2017, at 3:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > Pete Heist writes: >=20 >> I=E2=80=99ll mention one example I noticed of the kind of adjustment = that >> probably can=E2=80=99t be done from the qdisc layer today. On page 3 = from >> http://pollere.net/Pdfdocs/noteburstymacs.pdf: >>=20 >> "In addition to increasing the interval by the waiting delay s, >> another adjustment might be useful for certain kinds of bursty MACs. >> If the MAC is a request-and-grant type, as wifi in infrastructure >> mode, cable modems and some satellite modems, the allocation of bytes >> or packets that can be sent during each transmission slot is = generally >> known at the beginning of transmission and may vary for each >> transmission slot. In that case, it MAY be useful to use that value >> instead of the MTU value to reset first_above_time_." >=20 > Yeah, we've had this issue with CoDel when the per-station WiFi rate > drops too low (this is a function of both signal quality and number of > stations). As a temporary fix, I just fiddled with the target until > CoDel stopped being too aggressive, but that is not a proper solution, > and so has not been upstreamed. I'm planning to get back around to > fixing that properly at some point... Problem is that it is not always > the case that "the allocation of bytes or packets that can be sent > during each transmission slot is generally known". For ath9k we could > get at this information at dequeue time, but for ath10k, only the > firmware knows ahead of time... >=20 > -Toke Interesting, I hope there=E2=80=99s a solution. Here are the fixed MCS = level results I saw yesterday: http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png = http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png = in case anything can be seen in it related to this. I noticed that for = the ath9k driver CoDel latency maxed out at 45 ms at around MCS 10, and = didn=E2=80=99t get any higher down to MCS 8. Overall, the CoDel / Cake algorithms seem to keep rrul latency much = lower than sfq at lower bitrates, but the differences are smaller at = higher bitrates. More results later... Pete --Apple-Mail=_21CD7F56-7A38-4AB2-AED2-CF6F869E31D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 9, 2017, at 3:44 PM, Toke H=C3=B8iland-J=C3=B8rgensen = <toke@toke.dk> = wrote:

Pete Heist <peteheist@gmail.com> writes:

I=E2=80=99ll mention one = example I noticed of the kind of adjustment that
probably = can=E2=80=99t be done from the qdisc layer today. On page 3 from
http://pollere.net/Pdfdocs/noteburstymacs.pdf:

"In addition to increasing the interval by the = waiting delay s,
another adjustment might be useful for = certain kinds of bursty MACs.
If the MAC is a = request-and-grant type, as wifi in infrastructure
mode, = cable modems and some satellite modems, the allocation of bytes
or packets that can be sent during each transmission slot is = generally
known at the beginning of transmission and may = vary for each
transmission slot. In that case, it MAY be = useful to use that value
instead of the MTU value to reset = first_above_time_."

Yeah, = we've had this issue with CoDel when the per-station WiFi rate
drops too low (this is a function of both signal quality and = number of
stations). As a temporary fix, I just fiddled = with the target until
CoDel stopped being too aggressive, = but that is not a proper solution,
and so has not been = upstreamed. I'm planning to get back around to
fixing that = properly at some point... Problem is that it is not always
the case that "the allocation of bytes or packets that can be = sent
during each transmission slot is generally known". = For ath9k we could
get at this information at dequeue = time, but for ath10k, only the
firmware knows ahead of = time...

-Toke

Interesting, I hope there=E2=80=99s a solution. Here are the = fixed MCS level results I saw yesterday:

http://www.drhleny.cz/bufferbloat/mcstmp/mcs_latency.png

http://www.drhleny.cz/bufferbloat/mcstmp/mcs_throughput.png=

in case = anything can be seen in it related to this. I noticed that for the ath9k = driver CoDel latency maxed out at 45 ms at around MCS 10, and didn=E2=80=99= t get any higher down to MCS 8.

Overall, the CoDel / Cake algorithms = seem to keep rrul latency much lower than sfq at lower bitrates, but the = differences are smaller at higher bitrates. More results = later...

Pete

= --Apple-Mail=_21CD7F56-7A38-4AB2-AED2-CF6F869E31D8--