[OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Ben West]

Hello All,

I operate a small adhoc meshing network in a residential neighborhood,
presently based on AA r36669 running on a mixture of ar71xx and atheros
devices.

On a small test network comprised of three atheros nodes, which I use for
proving out new firmware, I noticed that AA r38346 demonstrates
dramatically worse throughput between nodes than the same firmware compiled
from r36669, with the nodes at identical locations / spacings.

I have not yet had the opportunity to test whether this apparent regression
also occurs on ar71xx devices.

Is there a preferred method for documenting or reporting speed regressions
on the mac80211 library, considering that accurately measuring such can be
so difficult?  Would it be best for me to attempt the same throughput tests
using firmware compiled against current trunk, to see if the regression is
also present there?

Thank you.

-- 
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Felix Fietkau]

On 2013-10-12 4:16 PM, Ben West wrote:
> Hello All,
> 
> I operate a small adhoc meshing network in a residential neighborhood,
> presently based on AA r36669 running on a mixture of ar71xx and atheros
> devices.
> 
> On a small test network comprised of three atheros nodes, which I use
> for proving out new firmware, I noticed that AA r38346 demonstrates
> dramatically worse throughput between nodes than the same firmware
> compiled from r36669, with the nodes at identical locations / spacings.
> 
> I have not yet had the opportunity to test whether this apparent
> regression also occurs on ar71xx devices.
> 
> Is there a preferred method for documenting or reporting speed
> regressions on the mac80211 library, considering that accurately
> measuring such can be so difficult?  Would it be best for me to attempt
> the same throughput tests using firmware compiled against current trunk,
> to see if the regression is also present there?
Yes. Please also mention the exact SoC and wifi chip types that you're
using, and how much the throughput changed (mbit/s before/after), and
how exactly you're doing the tests.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Bastian Bittorf]

* Ben West  [12.10.2013 18:27]:
> On a small test network comprised of three atheros nodes, which I use for
> proving out new firmware, I noticed that AA r38346 demonstrates
> dramatically worse throughput between nodes than the same firmware compiled
> from r36669, with the nodes at identical locations / spacings.

i noticed the some for me. here are only Ubiquiti Bullet M5 / ar71xx
involved, adhoc but longshots (1 neigh). Interesting also: before i used HT40+
and this is not possible anymore, _nearly_ no packet arrives on the
other side (HT20 is the same), i had to go down to 5 mhz channels now.

Change was from: r32582 -> r38043

the log is now full with 'ath: phy0: Failed to stop TX DMA'
(8000 lines in 14 hours). i will update on newest trunk monday.

bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[cmsv]

My mesh uses mostly dlink and tplink (ar71xx moslty athk9) and i am now
working with AA r38315 to deploy new firmware by the end of the year and
these news are serious concerning.I will be testing

The current firmware in the mesh is DISTRIB_REVISION="r35241" and i have
no problems with HT20 or HT40-


On 10/12/2013 12:35 PM, Bastian Bittorf wrote:
> * Ben West  [12.10.2013 18:27]:
>> On a small test network comprised of three atheros nodes, which I use for
>> proving out new firmware, I noticed that AA r38346 demonstrates
>> dramatically worse throughput between nodes than the same firmware compiled
>> from r36669, with the nodes at identical locations / spacings.
Could you provide some log and bandwidth test data analysis ? (before
and after)


> i noticed the some for me. here are only Ubiquiti Bullet M5 / ar71xx
> involved, adhoc but longshots (1 neigh). Interesting also: before i used HT40+
> and this is not possible anymore, _nearly_ no packet arrives on the
> other side (HT20 is the same), i had to go down to 5 mhz channels now.
> 
> Change was from: r32582 -> r38043
> 
> the log is now full with 'ath: phy0: Failed to stop TX DMA'
> (8000 lines in 14 hours). i will update on newest trunk monday.

With AA r35241 i have a few lines from time to time on some routers too
but not that many


> bye, bastian
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 



signature.asc
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Felix Fietkau]

On 2013-10-12 6:35 PM, Bastian Bittorf wrote:
> * Ben West  [12.10.2013 18:27]:
>> On a small test network comprised of three atheros nodes, which I use for
>> proving out new firmware, I noticed that AA r38346 demonstrates
>> dramatically worse throughput between nodes than the same firmware compiled
>> from r36669, with the nodes at identical locations / spacings.
> 
> i noticed the some for me. here are only Ubiquiti Bullet M5 / ar71xx
> involved, adhoc but longshots (1 neigh). Interesting also: before i used HT40+
> and this is not possible anymore, _nearly_ no packet arrives on the
> other side (HT20 is the same), i had to go down to 5 mhz channels now.
> 
> Change was from: r32582 -> r38043
> 
> the log is now full with 'ath: phy0: Failed to stop TX DMA'
> (8000 lines in 14 hours). i will update on newest trunk monday.
By the way, I also made a backport of the mac80211 package (+ hostapd)
from trunk to AA:
http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary
git://nbd.name/aa-mac80211.git
You can copy those into your AA build tree (after removing the old
packages).

Please run a test with those packages, I'm considering a backport from
trunk to AA due to recent reports of significant stability improvements.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Ben West]

The devices in 'production' use are Engenius EOC-01650 and Open Mesh OM1Ps,
both with Atheros SoC AR2315.  These are gradually by being replaced by
UBNT Nanostation Loco M2's, with SoC AR7240.

The small adhoc network I was using for proving firmware, where the
decrease in throughput was observed, is comprised of 3 EOC-1650's, hung up
at various locations around my building.

My simple speed test was just to wget a 500Mbyte file from a 100Mbit wired
LAN connected to one of the nodes across the adhoc network to /dev/null.
Indeed, iperf would be more precise, but wget seemed sufficient just to
allow me to observe large differences in throughput, e.g. 1Mbit/s vs
3Mbit/s average.

At any rate, is it preferred to compare throughput values I've observed
using AA r36669 with those observed running AA r38346, or with throughput
values measured using current trunk.  I understand that since AA only
receives a selection of backports from trunk, it can occasionally be a
hodgepodge of working vs suboptimal code.

Thank you.



On Sat, Oct 12, 2013 at 9:22 AM, Felix Fietkau  wrote:

> On 2013-10-12 4:16 PM, Ben West wrote:
> > Hello All,
> >
> > I operate a small adhoc meshing network in a residential neighborhood,
> > presently based on AA r36669 running on a mixture of ar71xx and atheros
> > devices.
> >
> > On a small test network comprised of three atheros nodes, which I use
> > for proving out new firmware, I noticed that AA r38346 demonstrates
> > dramatically worse throughput between nodes than the same firmware
> > compiled from r36669, with the nodes at identical locations / spacings.
> >
> > I have not yet had the opportunity to test whether this apparent
> > regression also occurs on ar71xx devices.
> >
> > Is there a preferred method for documenting or reporting speed
> > regressions on the mac80211 library, considering that accurately
> > measuring such can be so difficult?  Would it be best for me to attempt
> > the same throughput tests using firmware compiled against current trunk,
> > to see if the regression is also present there?
> Yes. Please also mention the exact SoC and wifi chip types that you're
> using, and how much the throughput changed (mbit/s before/after), and
> how exactly you're doing the tests.
>
> - Felix
>
>


-- 
Ben West
http://gowasabi.net
b...@gowasabi.net
314-246-9434
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Felix Fietkau]

On 2013-10-13 7:49 PM, Ben West wrote:
> The devices in 'production' use are Engenius EOC-01650 and Open Mesh
> OM1Ps, both with Atheros SoC AR2315.  These are gradually by being
> replaced by UBNT Nanostation Loco M2's, with SoC AR7240.
> 
> The small adhoc network I was using for proving firmware, where the
> decrease in throughput was observed, is comprised of 3 EOC-1650's, hung
> up at various locations around my building.
> 
> My simple speed test was just to wget a 500Mbyte file from a 100Mbit
> wired LAN connected to one of the nodes across the adhoc network to
> /dev/null.  Indeed, iperf would be more precise, but wget seemed
> sufficient just to allow me to observe large differences in throughput,
> e.g. 1Mbit/s vs 3Mbit/s average.
> 
> At any rate, is it preferred to compare throughput values I've observed
> using AA r36669 with those observed running AA r38346, or with
> throughput values measured using current trunk.  I understand that since
> AA only receives a selection of backports from trunk, it can
> occasionally be a hodgepodge of working vs suboptimal code.
You can use the full trunk backport by using the package from this
repository: http://nbd.name/gitweb.cgi?p=aa-mac80211.git;a=summary
I'd recommend comparing that with the older version.
In addition to the different throughput values, please also provide rate
control statistics from
/sys/kernel/debug/ieee80211/phy0/netdev:wlan0/stations/*/rc_stats

Thanks,

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Ben West]

Hi Felix,

I've tried testing both AA r38347 as-is, and also AA recompiled with the
back-ported copies of hostapd and mac80211 packages that you provided on
your git repo (thank you!).  Unfortunately, in both instances, I saw the
adhoc link between two Engenius EOC-1650 freeze entirely during a long wget
transfer.  That is, the transfer itself stalls, even ping packages don't
pass.  Several minutes after stopping the wget transfer, the adhoc returns
to normal.

Here are rate control stats on the remote node (i.e. the one not connected
to a wired LAN) before and after attempting the long wget transfer:

BEFORE

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate  throughput  ewma prob  this prob  this succ/attempt   success
attempts
   1 0.00.00.0 0(  5)
145783
   2 0.7   37.30.0 0(  1)
548 956
P  5.5   4.9   91.3  100.0 1(  1)
158 395
   D  11 6.0   59.1  100.0 0(  0)
267 643
   6 1.8   30.60.0 0(  0)
231 508
   9 3.3   37.20.0 0(  0)
349 727
  12 4.6   39.3   33.3 0(  0)
6411106
  C   18 6.0   34.80.0 0(  0)
351 698
 B2410.6   46.9  100.0 1(  1)
63 326
  36 4.6   14.20.0 0(  6)
156 627
  48 0.00.10.0 0(  0)
7712441
A 5424.2   52.3   33.3 1(  3)
8422721

Total packet count::ideal 5951  lookaround 664

AFTER

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate  throughput  ewma prob  this prob  this succ/attempt   success
attempts
   1 0.00.00.0 0(  6)
18   25581
   2 0.3   18.20.0 0(  0)
5641122
   5.5   3.3   62.0  100.0 0(  0)
4761159
  11 5.5   54.4  100.0 0(  0)
3391024
   6 2.2   37.7  100.0 0(  0)
39005892
   9 3.1   35.30.0 0(  0)
6141313
   D  12 7.9   67.0  100.0 0(  0)
6601374
  C   18 9.6   55.8   50.0 0(  0)
5361509
  24 3.7   16.5   33.3 0(  0)
2641248
  36 6.7   20.90.0 0(  0)
166 867
A   P 4827.9   67.2  100.0 0(  0)
16825160
 B5413.4   29.0   33.3 0(  0)
3788   10223

Total packet count::ideal 8510  lookaround 946

On both devices running AA r36669, long wget transfers work fine.  In my
instance, the transfers averaged to 415Bytes/sec over a single test that
moved 2GBytes.  For comparison, below are the rc_stats on this same device
running AA r36669, before and after a successful long transfer. I do notice
that r36669 reports 0 throughput at higher rates like 54Mbit/s, unlike
r38347.  Maybe throughput is being measured inaccurately?

BEFORE

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats

rate throughput  ewma prob   this prob  this succ/attempt   success
attempts
   1 0.5   52.2  100.0  0(  0)
25  39
   2 1.2   63.0  100.0  0(  0)
4   7
   5.5   3.1   58.9  100.0  0(  0)
4   6
 B  P 11 8.7   86.0  100.0  0(  0)
10  11
   6 4.0   66.8  100.0  0(  0)
5   6
   9 4.7   52.50.0  0(  0)
79 167
  C   12 7.3   62.2  100.0  0(  0)
4  11
A 1811.7   67.5   50.0  1(  2)
587 969
   D  24 5.0   22.2   19.9  0(  0)
4  34
  36 0.00.00.0  0(  0)
0  12
  48 0.00.00.0  0(  0)
0  12
  54 0.00.00.0  0(  0)
0  12

Total packet count::ideal 653  lookaround 72

AFTER

root@WasabiNet-mushmaus:~# cat
/sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
rate throughput  ewma prob   this prob  this succ/attempt   success
attempts
   1 0.00.00.0  0(  0)   1657
32236
   2 1.2   60.5  100.0  0(  0)   8632
16530
   5.5   1.6   31.30.0   

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Ben West]

Also, sorry for typo: "transfers averaged to *415KBytes/sec* ..."


On Mon, Oct 14, 2013 at 10:55 AM, Ben West  wrote:

> Hi Felix,
>
> I've tried testing both AA r38347 as-is, and also AA recompiled with the
> back-ported copies of hostapd and mac80211 packages that you provided on
> your git repo (thank you!).  Unfortunately, in both instances, I saw the
> adhoc link between two Engenius EOC-1650 freeze entirely during a long wget
> transfer.  That is, the transfer itself stalls, even ping packages don't
> pass.  Several minutes after stopping the wget transfer, the adhoc returns
> to normal.
>
> Here are rate control stats on the remote node (i.e. the one not connected
> to a wired LAN) before and after attempting the long wget transfer:
>
> BEFORE
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt   success
> attempts
>1 0.00.00.0 0(  5)
> 145783
>2 0.7   37.30.0 0(  1)
> 548 956
> P  5.5   4.9   91.3  100.0 1(  1)
> 158 395
>D  11 6.0   59.1  100.0 0(  0)
> 267 643
>6 1.8   30.60.0 0(  0)
> 231 508
>9 3.3   37.20.0 0(  0)
> 349 727
>   12 4.6   39.3   33.3 0(  0)
> 6411106
>   C   18 6.0   34.80.0 0(  0)
> 351 698
>  B2410.6   46.9  100.0 1(  1)
> 63 326
>   36 4.6   14.20.0 0(  6)
> 156 627
>   48 0.00.10.0 0(  0)
> 7712441
> A 5424.2   52.3   33.3 1(  3)
> 8422721
>
> Total packet count::ideal 5951  lookaround 664
>
> AFTER
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt   success
> attempts
>1 0.00.00.0 0(  6)
> 18   25581
>2 0.3   18.20.0 0(  0)
> 5641122
>5.5   3.3   62.0  100.0 0(  0)
> 4761159
>   11 5.5   54.4  100.0 0(  0)
> 3391024
>6 2.2   37.7  100.0 0(  0)
> 39005892
>9 3.1   35.30.0 0(  0)
> 6141313
>D  12 7.9   67.0  100.0 0(  0)
> 6601374
>   C   18 9.6   55.8   50.0 0(  0)
> 5361509
>   24 3.7   16.5   33.3 0(  0)
> 2641248
>   36 6.7   20.90.0 0(  0)
> 166 867
> A   P 4827.9   67.2  100.0 0(  0)
> 16825160
>  B5413.4   29.0   33.3 0(  0)
> 3788   10223
>
> Total packet count::ideal 8510  lookaround 946
>
> On both devices running AA r36669, long wget transfers work fine.  In my
> instance, the transfers averaged to 415Bytes/sec over a single test that
> moved 2GBytes.  For comparison, below are the rc_stats on this same device
> running AA r36669, before and after a successful long transfer. I do notice
> that r36669 reports 0 throughput at higher rates like 54Mbit/s, unlike
> r38347.  Maybe throughput is being measured inaccurately?
>
> BEFORE
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
>
> rate throughput  ewma prob   this prob  this succ/attempt   success
> attempts
>1 0.5   52.2  100.0  0(  0)
> 25  39
>2 1.2   63.0  100.0  0(  0)
> 4   7
>5.5   3.1   58.9  100.0  0(  0)
> 4   6
>  B  P 11 8.7   86.0  100.0  0(  0)
> 10  11
>6 4.0   66.8  100.0  0(  0)
> 5   6
>9 4.7   52.50.0  0(  0)
> 79 167
>   C   12 7.3   62.2  100.0  0(  0)
> 4  11
> A 1811.7   67.5   50.0  1(  2)
> 587 969
>D  24 5.0   22.2   19.9  0(  0)
> 4  34
>   36 0.00.00.0  0(  0)
> 0  12
>   48 0.00.00.0  0(  0)
> 0  12
>   54 0.00.00.0  0(  0)
> 0  12
>
> Total packet count::ideal 653  lookaround 72
>
> AFTER
>
> root@WasabiNet-mushmaus:~# cat
> /sys/kernel/debug/i

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Felix Fietkau]

Hi Ben,

please try copying this patch to package/mac80211/patches (with the new
version): http://nbd.name/990-ath5k_fix.patch
I checked the ath5k diff between the old and the new version, and the
only relevant change seems to be a rate control related rework.

- Felix

On 2013-10-14 5:56 PM, Ben West wrote:
> Also, sorry for typo: "transfers averaged to *415KBytes/sec* ..."
> 
> 
> On Mon, Oct 14, 2013 at 10:55 AM, Ben West  > wrote:
> 
> Hi Felix,
> 
> I've tried testing both AA r38347 as-is, and also AA recompiled with
> the back-ported copies of hostapd and mac80211 packages that you
> provided on your git repo (thank you!).  Unfortunately, in both
> instances, I saw the adhoc link between two Engenius EOC-1650 freeze
> entirely during a long wget transfer.  That is, the transfer itself
> stalls, even ping packages don't pass.  Several minutes after
> stopping the wget transfer, the adhoc returns to normal.
> 
> Here are rate control stats on the remote node (i.e. the one not
> connected to a wired LAN) before and after attempting the long wget
> transfer:
> 
> BEFORE
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt  
> successattempts
>1 0.00.00.0 0(  5)   
> 145783
>2 0.7   37.30.0 0(  1)  
> 548 956
> P  5.5   4.9   91.3  100.0 1(  1)  
> 158 395
>D  11 6.0   59.1  100.0 0(  0)  
> 267 643
>6 1.8   30.60.0 0(  0)  
> 231 508
>9 3.3   37.20.0 0(  0)  
> 349 727
>   12 4.6   39.3   33.3 0(  0)  
> 6411106
>   C   18 6.0   34.80.0 0(  0)  
> 351 698
>  B2410.6   46.9  100.0 1(  1)   
> 63 326
>   36 4.6   14.20.0 0(  6)  
> 156 627
>   48 0.00.10.0 0(  0)  
> 7712441
> A 5424.2   52.3   33.3 1(  3)  
> 8422721
> 
> Total packet count::ideal 5951  lookaround 664
> 
> AFTER
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> rate  throughput  ewma prob  this prob  this succ/attempt  
> successattempts
>1 0.00.00.0 0(  6)   
> 18   25581
>2 0.3   18.20.0 0(  0)  
> 5641122
>5.5   3.3   62.0  100.0 0(  0)  
> 4761159
>   11 5.5   54.4  100.0 0(  0)  
> 3391024
>6 2.2   37.7  100.0 0(  0) 
> 39005892
>9 3.1   35.30.0 0(  0)  
> 6141313
>D  12 7.9   67.0  100.0 0(  0)  
> 6601374
>   C   18 9.6   55.8   50.0 0(  0)  
> 5361509
>   24 3.7   16.5   33.3 0(  0)  
> 2641248
>   36 6.7   20.90.0 0(  0)  
> 166 867
> A   P 4827.9   67.2  100.0 0(  0) 
> 16825160
>  B5413.4   29.0   33.3 0(  0) 
> 3788   10223
> 
> Total packet count::ideal 8510  lookaround 946
> 
> On both devices running AA r36669, long wget transfers work fine. 
> In my instance, the transfers averaged to 415Bytes/sec over a single
> test that moved 2GBytes.  For comparison, below are the rc_stats on
> this same device running AA r36669, before and after a successful
> long transfer. I do notice that r36669 reports 0 throughput at
> higher rates like 54Mbit/s, unlike r38347.  Maybe throughput is
> being measured inaccurately?
> 
> BEFORE
> 
> root@WasabiNet-mushmaus:~# cat
> 
> /sys/kernel/debug/ieee80211/phy0/netdev\:wlan0-1/stations/06\:02\:6f\:76\:13\:53/rc_stats
> 
> rate throughput  ewma prob   this prob  this succ/attempt  
> successattempts
>1 0.5   52.2  100.0  0(  0)
> 25  39
>2 1.2   63.0  100.0  0(  0) 
> 4   7
> 

Re: [OpenWrt-Devel] Best approach for reporting apparent throughput regression in mac80211 / atheros platform?

[Felix Fietkau]

Hi Ben,

On 2013-10-14 9:01 PM, Ben West wrote:
> Hi Felix,
> 
> This is fabulous.  The adhoc link between the 2 Engenius nodes now
> passed the 2Gbyte transfer test, running AA r38347 with the hostapd +
> mac80211 backports/patches which you have provided.  In addition, I
> measured a mild speed increase from avg *423Kbytes/sec* with AA r36669
> to *505Kbytes/sec* with the patched AA r38347.
Thanks for testing. I've committed this fix to both trunk and 12.09, and
I've also submitted it to linux-wireless for upstream inclusion (you've
been Cc'd).

> For others following this thread, I'm including the bzipped diffs of my
> local AA r38347 build tree.  These diffs contain Felix's proposed
> backports to AA for the packages mac80211 and hostapd, including the
> ath5k rate control patch Felix just offered today.  Likewise, my hostapd
> diff also includes a patch to restore the "beacon_int" parameter in
> /etc/config/wireless, which has been mentioned in a couple other recent
> threads.
> 
> Are additional steps needed to get these backports committed into AA? 
> Including the beacon_int patch?
I'll look into it. At some point in the near future, I plan on
backporting the full mac80211 and hostapd packages to AA.

> Thank you!
> 
> P.S. Good meeting you earlier this month at IS4CWN.
Good meeting you too.

- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel