Date: Fri, 9 Sep 2011 15:46:14 +0400 From: Lev Serebryakov <lev@serebryakov.spb.ru> To: Adrian Chadd <adrian@freebsd.org> Cc: freebsd-wireless@freebsd.org Subject: Re: AP performance (again): txpower regulation Message-ID: <140679489.20110909154614@serebryakov.spb.ru> In-Reply-To: <CAJ-VmokAvtKTUGo5zBS3ry0nRH=P%2B1TNB2n-9dKK%2BSWn6FdJ2A@mail.gmail.com> References: <663133681.20110907193747@serebryakov.spb.ru> <CAJ-Vmonai4LzwanLw7i5d-NyjN2b6GqfttjkdcROvOuEcuzEAw@mail.gmail.com> <437702009.20110907235248@serebryakov.spb.ru> <CAJ-Vmo=R-a%2BqhDLWj1n%2BBj70Pmg4WSL6bVZ6jwCUmNq=v7EBBw@mail.gmail.com> <426917282.20110908125907@serebryakov.spb.ru> <CAAUsrB5Qtokpcz-koUfYWCHrsnUUErQSAYHrXrW2F0Uvp3RzSA@mail.gmail.com> <4610390305.20110908154130@serebryakov.spb.ru> <CAAUsrB6LJ%2BmuTvaqHCySh6e9dMjzshohYFE4PQ3KTezZMZS2JA@mail.gmail.com> <1705262661.20110908180850@serebryakov.spb.ru> <CAAUsrB7CFu096x%2BKKWa=8O_VeSHOK10LuwJ2rWq6r8EidUrL=Q@mail.gmail.com> <CAJ-VmokvXfUAZpxDgv5gLrRdLYn3YwTXAOb7QiTyUg8K5yKLHg@mail.gmail.com> <458771414.20110908183656@serebryakov.spb.ru> <CAJ-Vmom_ZHKbqt%2BQgmdq_oPU-SugbrJ3LNS=g-cpcQ7KExusUw@mail.gmail.com> <4910491962.20110908185213@serebryakov.spb.ru> <CAJ-Vmo==J_9ZhnSciVKNaEaMhM4oeM9fr4yjzPev_MW3g9DALg@mail.gmail.com> <1273865639.20110908191303@serebryakov.spb.ru> <1607911768.20110909113824@serebryakov.spb.ru> <CAJ-Vm onfU0iJUiC%2BhT32XvH3t9qwKy98o9GdxMZxqebcSPL04Q@mail.gmail.com> <1853154884.20110909145338@serebryakov.spb.ru> <CAJ-VmokAvtKTUGo5zBS3ry0nRH=P%2B1TNB2n-9dKK%2BSWn6FdJ2A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Adrian.
You wrote 9 =F1=E5=ED=F2=FF=E1=F0=FF 2011 =E3., 15:06:03:
> I'd suggest looking at the output of athstats whilst you're doing traffic:
> $ athstats 1
Ok. It looks not so bad. AP sends UDP to client, 54Mbit limit (real
rtate is about 4-5Mbit):
input output altrate short long xretry crcerr crypt phyerr rssi =
rate
1190628 1985635 73453 0 1305995 27990 22934 0 215 36 =
54M
18 477 21 0 380 8 0 0 0 34 =
24M
19 578 25 0 414 8 1 0 0 37 =
54M
18 549 21 0 394 8 0 0 0 37 =
54M
19 611 19 0 420 9 0 0 0 37 =
54M
16 570 37 0 483 8 0 0 0 37 =
54M
21 319 34 0 472 11 0 0 1 37 =
24M
19 479 18 0 371 8 0 0 0 36 =
54M
25 406 19 0 355 8 1 0 0 36 =
24M
10 487 28 0 347 5 0 0 0 37 =
54M
20 467 22 0 368 8 0 0 0 38 =
54M
18 708 18 0 389 8 0 0 0 38 =
54M
24 575 20 0 377 9 0 0 0 38 =
54M
21 449 20 0 360 7 2 0 0 37 =
24M
19 478 40 0 482 8 0 0 0 43 =
24M
15 563 10 0 306 6 1 0 0 43 =
54M
22 480 32 0 434 7 0 0 0 43 =
54M
19 608 19 0 364 5 0 0 0 45 =
24M
17 730 14 0 373 8 0 0 0 44 =
24M
22 573 15 0 351 9 0 0 0 45 =
54M
18 425 8 0 279 6 0 0 0 44 =
54M
It looks like xretry is about 2%. It doesn't look bad. And almost 50%
of time it should be 54M and it doesn't drop under 24M.
> And look at the output of the sample rate control algorithm:
> # sysctl dev.ath.0.sample_stats=3D1
> (then check dmesg)
[00:18:de:08:e8:1d] refcnt 565 static_rix -1 ratemask 0xfcf
[ 250] cur rix 7 (18 Mb ) since switch: packets 9 ticks 5035977
[ 250] last sample 8 cur sample -1 packets sent 53
[ 250] packets since sample 9 sample tt 492
[1600] cur rix 11 (54 Mb ) since switch: packets 365 ticks 5412324
[1600] last sample 10 cur sample -1 packets sent 550587
[1600] packets since sample 8 sample tt 6572
[ 1 Mb : 250] 8:8 (100%) T 12 F 0 avg 5788 last 577=
382
[ 1 Mb :1600] 11064:2392 ( 21%) T 29614 F 8 avg 27007 last 41
[ 2 Mb :1600] 662:365 ( 55%) T 3538 F 1 avg 54480 last 5381
[ 5 Mb :1600] 2771:2313 ( 83%) T 8758 F 0 avg 25327 last 2637
[11 Mb :1600] 30750:29636 ( 96%) T 46928 F 0 avg 13938 last 809
[12 Mb : 250] 3:3 (100%) T 4 F 0 avg 862 last 667=
362
[12 Mb :1600] 15715:11224 ( 71%) T 53044 F 1 avg 16555 last 35
[18 Mb : 250] 13:13 (100%) T 15 F 0 avg 644 last 377=
066
[18 Mb :1600] 26291:20704 ( 78%) T 92818 F 0 avg 12800 last 31
[24 Mb : 250] 23:23 (100%) T 28 F 0 avg 773 last 557=
829
[24 Mb :1600] 254064:240957 ( 94%) T 451739 F 0 avg 1811 last 1
[36 Mb : 250] 4:4 (100%) T 6 F 0 avg 978 last 187=
3005
[36 Mb :1600] 66351:58850 ( 88%) T 149091 F 0 avg 13597 last 208
[48 Mb : 250] 10:10 (100%) T 15 F 0 avg 805 last 562=
244
[48 Mb :1600] 33675:28151 ( 83%) T 114032 F 0 avg 11914 last 2
[54 Mb : 250] 1:0 ( 0%) T 5 F 1 avg 5407 last 227=
9726
[54 Mb :1600] 170731:158102 ( 92%) T 316993 F 0 avg 1016 last 4
> Let's split it into two halves: TX and RX. For TX errors, you'll see
> things like ackbad, long/short retries. For RX errors, you'll see lots
> of CRC errors.
Other way round, client sends UDP:
input output altrate short long xretry crcerr crypt phyerr rssi =
rate
1276120 2183304 79113 0 1427069 30743 28858 0 234 38 =
54M
1128 107 14 0 202 7 106 0 0 39 =
54M
1085 104 18 0 209 6 55 0 0 35 =
54M
1248 109 1 0 103 6 149 0 0 39 =
24M
1067 104 2 0 96 3 144 0 0 39 =
24M
1027 108 2 0 100 5 43 0 0 39 =
24M
1201 103 4 0 105 4 101 0 0 39 =
24M
1172 109 2 0 109 5 83 0 0 37 =
24M
1109 110 1 0 70 4 48 0 0 36 =
24M
1251 107 2 0 62 2 33 0 0 38 =
24M
1115 110 2 0 98 4 79 0 0 40 =
24M
1055 108 1 0 89 4 71 0 0 40 =
24M
1189 108 1 0 102 6 35 0 0 39 =
24M
1204 105 3 0 109 5 105 0 0 38 =
24M
1321 104 1 0 80 5 122 0 0 37 =
24M
994 108 3 0 98 5 61 0 0 38 =
24M
904 108 5 0 143 6 96 0 0 38 =
24M
968 107 3 0 110 4 73 0 1 36 =
24M
1169 103 0 0 80 4 39 0 0 39 =
11M
1155 108 3 0 96 4 94 0 0 38 =
18M
1284 108 1 0 63 4 125 0 0 38 =
24M
CRC errors is about 10%. Not good...
And sample rate output:
[00:18:de:08:e8:1d] refcnt 3 static_rix -1 ratemask 0xfcf
[ 250] cur rix 8 (24 Mb ) since switch: packets 2 ticks 5768421
[ 250] last sample 7 cur sample -1 packets sent 79
[ 250] packets since sample 2 sample tt 1317
[1600] cur rix 8 (24 Mb ) since switch: packets 57 ticks 5771528
[1600] last sample 6 cur sample -1 packets sent 670528
[1600] packets since sample 69 sample tt 37745
[ 1 Mb : 250] 10:10 (100%) T 15 F 0 avg 5656 last 405=
48
[ 1 Mb :1600] 13208:2737 ( 20%) T 35551 F 0 avg 28160 last 869
[ 2 Mb :1600] 780:395 ( 50%) T 4264 F 1 avg 59404 last 232=
32
[ 5 Mb :1600] 3088:2541 ( 82%) T 10072 F 0 avg 23252 last 878
[11 Mb : 250] 1:1 (100%) T 6 F 0 avg 18948 last 406=
17
[11 Mb :1600] 35830:34548 ( 96%) T 54574 F 0 avg 5453 last 885
[12 Mb : 250] 5:5 (100%) T 14 F 0 avg 4996 last 406=
47
[12 Mb :1600] 16751:11586 ( 69%) T 58615 F 0 avg 29124 last 855
[18 Mb : 250] 28:27 ( 96%) T 44 F 0 avg 1840 last 273=
30
[18 Mb :1600] 27823:21543 ( 77%) T 101709 F 0 avg 27987 last 879
[24 Mb : 250] 31:30 ( 96%) T 40 F 0 avg 886 last 2506
[24 Mb :1600] 292880:278615 ( 95%) T 512732 F 0 avg 1224 last 82
[36 Mb : 250] 6:6 (100%) T 10 F 0 avg 1149 last 386=
19
[36 Mb :1600] 69311:60752 ( 87%) T 161093 F 0 avg 9474 last 1130
[48 Mb : 250] 12:11 ( 91%) T 23 F 0 avg 1332 last 386=
19
[48 Mb :1600] 37809:31186 ( 82%) T 135498 F 0 avg 11207 last 1054
[54 Mb : 250] 1:0 ( 0%) T 5 F 1 avg 5407 last 263=
8461
[54 Mb :1600] 245282:229102 ( 93%) T 437345 F 4 avg 9288 last 399=
72
> Finally, I bet yes - running the NIC at half its rated TX power is
> likely going to make things easier to deal with. It won't be using the
> full TX power at higher rates anyway- ie, although the NIC is rated at
> 600mW, that'll be at the lowest TX rates (1MBit), I bet at 54MBit it's
> only transmitting at 100mW. Since you want to get higher throughput,
> why run the NIC at a higher TX power than what the 54mbit rate will TX
> at? :)
:) Slightly more -- 23dBm, where 20dBm is 100mW :) But I limited
card to 20 (100mW) with exactly the same result.
--=20
// Black Lion AKA Lev Serebryakov <lev@serebryakov.spb.ru>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?140679489.20110909154614>