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.0        0.0        0.0             0(  5)
14        5783
       2         0.7       37.3        0.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.6        0.0             0(  0)
231         508
       9         3.3       37.2        0.0             0(  0)
349         727
      12         4.6       39.3       33.3             0(  0)
641        1106
  C   18         6.0       34.8        0.0             0(  0)
351         698
 B    24        10.6       46.9      100.0             1(  1)
63         326
      36         4.6       14.2        0.0             0(  6)
156         627
      48         0.0        0.1        0.0             0(  0)
771        2441
A     54        24.2       52.3       33.3             1(  3)
842        2721

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.0        0.0        0.0             0(  6)
18       25581
       2         0.3       18.2        0.0             0(  0)
564        1122
       5.5       3.3       62.0      100.0             0(  0)
476        1159
      11         5.5       54.4      100.0             0(  0)
339        1024
       6         2.2       37.7      100.0             0(  0)
3900        5892
       9         3.1       35.3        0.0             0(  0)
614        1313
   D  12         7.9       67.0      100.0             0(  0)
660        1374
  C   18         9.6       55.8       50.0             0(  0)
536        1509
      24         3.7       16.5       33.3             0(  0)
264        1248
      36         6.7       20.9        0.0             0(  0)
166         867
A   P 48        27.9       67.2      100.0             0(  0)
1682        5160
 B    54        13.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.5        0.0          0(  0)
79         167
  C   12         7.3       62.2      100.0          0(  0)
4          11
A     18        11.7       67.5       50.0          1(  2)
587         969
   D  24         5.0       22.2       19.9          0(  0)
4          34
      36         0.0        0.0        0.0          0(  0)
0          12
      48         0.0        0.0        0.0          0(  0)
0          12
      54         0.0        0.0        0.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.0        0.0        0.0          0(  0)       1657
32236
       2         1.2       60.5      100.0          0(  0)       8632
16530
       5.5       1.6       31.3        0.0          0(  0)      14387
31865
  C   11         4.9       48.4        8.3          0(  0)     107143
238102
       6         2.9       49.4      100.0          1(  1)       5839
20081
 B     9         5.2       58.0       50.0          0(  0)      10665
38516
      12         3.3       28.1        0.0          0(  0)      40247
120171
A   P 18        12.6       73.0       72.2         13( 18)     369301
883412
   D  24         4.6       20.3       33.3          0(  0)     296475
1216256
      36         0.0        8.3        0.0          0(  0)      37298
330903
      48         0.0        9.3        0.0          0(  0)      13596
222798
      54         0.0        7.7        0.0          0(  0)      34449
388569

Total packet count::    ideal 8629      lookaround 958


On Sun, Oct 13, 2013 at 1:21 PM, Felix Fietkau <n...@openwrt.org> wrote:

> 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
>



-- 
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

Reply via email to