low throughputs with 14e4:4353

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

Hi Rafal,

I bought some 43224 cards to begin playing with the firmware. Unfortunately I have problems with the throughput that is really low. Kernel is the latest from wireless git and firmware comes from broadcom-wl-5.100.138. I see that the transmitted power is low, I monitored it with a spectrum analyzer and it confirmed. A lot of packets are lost given the low power and minstrel always select 1Mb/s. When receiving with the 43224 in monitor mode, I see that it receives only a few of the frames that are received by a close 4318-based box: the reported power levels are low too. Please find attached all info about kernel/firmware and devices below.

I tried all the four cards I have and they behave the same: find a photo of one of them here

	http://www.ing.unibs.it/gringoli/foto.JPG

I tried the cards on a MacBook White, on an Intel Atom based motherboard, Intel Pentium, and AMD Sempron, and I always got very low throughput. The same cards, with the same antennas (everything untouched) but with brcmsmac work well and the spectrum analyzer reports "normal" emitted power levels.

KR,
-Francesco

Linux version 3.2.0-rc2-wl+ (unibs at costanza.ing.unibs.it) (gcc version 4.1.2 20070626 (Red Hat 4.1.2-13)) #4 SMP Mon Nov 28 19:29:00 CET 2011

[    9.892975] b43-phy0: Broadcom 43224 WLAN found (core revision 23)
[    9.893403] b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 6
[    9.893415] b43-phy0 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 11
[  109.516058] b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
[  109.568056] b43-phy0 debug: Chip initialized
[  109.568208] b43-phy0 debug: 64-bit DMA initialized
[  109.568272] b43-phy0 debug: QoS enabled
[  109.568765] b43-phy0 debug: Wireless interface started
[  109.569035] b43-phy0 debug: Adding Interface type 2

02:00.0 0280: 14e4:4353 (rev 01)
	Subsystem: 103c:1509
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 256 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory@d0100000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: bcma-pci-bridge
	Kernel modules: bcma

low throughputs with 14e4:4353

[Rafał Miłecki]

Hey Francesco,

W dniu 29 listopada 2011 20:28 u?ytkownik
<francesco.gringoli@ing.unibs.it> napisa?:
> Hi Rafal,
>
> I bought some 43224 cards to begin playing with the firmware. Unfortunately I have problems with the throughput that is really low. Kernel is the latest from wireless git and firmware comes from broadcom-wl-5.100.138. I see that the transmitted power is low, I monitored it with a spectrum analyzer and it confirmed. A lot of packets are lost given the low power and minstrel always select 1Mb/s. When receiving with the 43224 in monitor mode, I see that it receives only a few of the frames that are received by a close 4318-based box: the reported power levels are low too. Please find attached all info about kernel/firmware and devices below.
>
> I tried all the four cards I have and they behave the same: find a photo of one of them here
>
> ? ? ? ?http://www.ing.unibs.it/gringoli/foto.JPG
>
> I tried the cards on a MacBook White, on an Intel Atom based motherboard, Intel Pentium, and AMD Sempron, and I always got very low throughput. The same cards, with the same antennas (everything untouched) but with brcmsmac work well and the spectrum analyzer reports "normal" emitted power levels.

I'm fighting with my BCM43224 for last 2 days, I reproduced the
problem with poor throughput. I already have some patches but nothing
improving situation so far. If I discover anything, I promise to share
:)

-- 
Rafa?

low throughputs with 14e4:4353

[Rafał Miłecki]

W dniu 29 listopada 2011 21:08 u?ytkownik Rafa? Mi?ecki
<zajec5@gmail.com> napisa?:
> Hey Francesco,
>
> W dniu 29 listopada 2011 20:28 u?ytkownik
> <francesco.gringoli@ing.unibs.it> napisa?:
>> Hi Rafal,
>>
>> I bought some 43224 cards to begin playing with the firmware. Unfortunately I have problems with the throughput that is really low. Kernel is the latest from wireless git and firmware comes from broadcom-wl-5.100.138. I see that the transmitted power is low, I monitored it with a spectrum analyzer and it confirmed. A lot of packets are lost given the low power and minstrel always select 1Mb/s. When receiving with the 43224 in monitor mode, I see that it receives only a few of the frames that are received by a close 4318-based box: the reported power levels are low too. Please find attached all info about kernel/firmware and devices below.
>>
>> I tried all the four cards I have and they behave the same: find a photo of one of them here
>>
>> ? ? ? ?http://www.ing.unibs.it/gringoli/foto.JPG
>>
>> I tried the cards on a MacBook White, on an Intel Atom based motherboard, Intel Pentium, and AMD Sempron, and I always got very low throughput. The same cards, with the same antennas (everything untouched) but with brcmsmac work well and the spectrum analyzer reports "normal" emitted power levels.
>
> I'm fighting with my BCM43224 for last 2 days, I reproduced the
> problem with poor throughput. I already have some patches but nothing
> improving situation so far. If I discover anything, I promise to share
> :)

After trying some "next" patch while my development, my card started
working. I've managed to associate and authenticate. I hoped I've
implemented some lacking part, and found the cure.

Then I reverted all my patches and... card is still working :( Of
course I'm doing cold boot for every test.

I'll give it a rest and will try in next days again.

-- 
Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Nov 29, 2011, at 10:36 PM, Rafa? Mi?ecki wrote:

> W dniu 29 listopada 2011 21:08 u?ytkownik Rafa? Mi?ecki
> <zajec5@gmail.com> napisa?:
>> Hey Francesco,
>> 
>> W dniu 29 listopada 2011 20:28 u?ytkownik
>> <francesco.gringoli@ing.unibs.it> napisa?:
>>> Hi Rafal,
>>> 
>>> I bought some 43224 cards to begin playing with the firmware. Unfortunately I have problems with the throughput that is really low. Kernel is the latest from wireless git and firmware comes from broadcom-wl-5.100.138. I see that the transmitted power is low, I monitored it with a spectrum analyzer and it confirmed. A lot of packets are lost given the low power and minstrel always select 1Mb/s. When receiving with the 43224 in monitor mode, I see that it receives only a few of the frames that are received by a close 4318-based box: the reported power levels are low too. Please find attached all info about kernel/firmware and devices below.
>>> 
>>> I tried all the four cards I have and they behave the same: find a photo of one of them here
>>> 
>>>        http://www.ing.unibs.it/gringoli/foto.JPG
>>> 
>>> I tried the cards on a MacBook White, on an Intel Atom based motherboard, Intel Pentium, and AMD Sempron, and I always got very low throughput. The same cards, with the same antennas (everything untouched) but with brcmsmac work well and the spectrum analyzer reports "normal" emitted power levels.
>> 
>> I'm fighting with my BCM43224 for last 2 days, I reproduced the
>> problem with poor throughput. I already have some patches but nothing
>> improving situation so far. If I discover anything, I promise to share
>> :)
> 
> After trying some "next" patch while my development, my card started
> working. I've managed to associate and authenticate. I hoped I've
> implemented some lacking part, and found the cure.
> 
> Then I reverted all my patches and... card is still working :( Of
> course I'm doing cold boot for every test.
> 
> I'll give it a rest and will try in next days again.
Larry,

I found your message on linux-wireless (end of July) reporting that the throughput was about 10Mb/s with bcma. You mention kernel "master-2011-07-26-150-g4ea94a9". I gave it a try (it is a 3.0.0 if I'm not wrong) but I'm still having very low throughput.

Rafal: so you observe good/bad throughputs at random? Sometimes after cold boot it works fine, other times bad?

Did you modprobe using some options?

Many thanks,
-Francesco

> 
> -- 
> Rafa?

low throughputs with 14e4:4353

[Larry Finger]

On 11/30/2011 09:05 AM, francesco.gringoli at ing.unibs.it wrote:
> Larry,
>
> I found your message on linux-wireless (end of July) reporting that the throughput was about 10Mb/s with bcma. You mention kernel "master-2011-07-26-150-g4ea94a9". I gave it a try (it is a 3.0.0 if I'm not wrong) but I'm still having very low throughput.
>
> Rafal: so you observe good/bad throughputs at random? Sometimes after cold boot it works fine, other times bad?
>
> Did you modprobe using some options?

My netperf results (3 sec samples) are:

TCP_MAERTS Test:  13.60 14.41 16.05 15.01 14.70 15.36 14.72 15.07 12.37 11.01
Results: max 16.05, min 11.01. Mean 14.23(1.44)

TCP_STREAM Test:   3.00  1.89  1.23  2.12  0.91  1.59  1.46  0.71  1.99  2.12
Results: max  3.00, min  0.71. Mean  1.70(0.64)

As you can see, RX is OK, but TX is quite low.

I will run the same test with brcmsmac later. Their damned Kconfig won't let me 
build both b43 and brcmsmac at the same time.

Larry

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Nov 30, 2011, at 10:27 PM, Larry Finger wrote:

> On 11/30/2011 09:05 AM, francesco.gringoli at ing.unibs.it wrote:
>> Larry,
>> 
>> I found your message on linux-wireless (end of July) reporting that the throughput was about 10Mb/s with bcma. You mention kernel "master-2011-07-26-150-g4ea94a9". I gave it a try (it is a 3.0.0 if I'm not wrong) but I'm still having very low throughput.
>> 
>> Rafal: so you observe good/bad throughputs at random? Sometimes after cold boot it works fine, other times bad?
>> 
>> Did you modprobe using some options?
> 
> My netperf results (3 sec samples) are:
> 
> TCP_MAERTS Test:  13.60 14.41 16.05 15.01 14.70 15.36 14.72 15.07 12.37 11.01
> Results: max 16.05, min 11.01. Mean 14.23(1.44)
> 
> TCP_STREAM Test:   3.00  1.89  1.23  2.12  0.91  1.59  1.46  0.71  1.99  2.12
> Results: max  3.00, min  0.71. Mean  1.70(0.64)
> 
> As you can see, RX is OK, but TX is quite low.
> 
> I will run the same test with brcmsmac later. Their damned Kconfig won't let me build both b43 and brcmsmac at the same time.
Larry, Rafal,

I can now confirm that with kernel 3.0.0-wl everything is ok, tx power is as expected and in fact I achieve up to 23Mb/s (iperf) on free channels. With latest kernel (I'm talking about 3.2.0-rc3-wl) I believe that the initialization of the radio is broken and, in fact, tx power is the lowest possible. I will bisect to check when the problem was introduced.

Cheers,
-Francesco

> 
> Larry
> 
> 
> 

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Nov 30, 2011, at 10:27 PM, Larry Finger wrote:

> On 11/30/2011 09:05 AM, francesco.gringoli at ing.unibs.it wrote:
>> Larry,
>> 
>> I found your message on linux-wireless (end of July) reporting that the throughput was about 10Mb/s with bcma. You mention kernel "master-2011-07-26-150-g4ea94a9". I gave it a try (it is a 3.0.0 if I'm not wrong) but I'm still having very low throughput.
>> 
>> Rafal: so you observe good/bad throughputs at random? Sometimes after cold boot it works fine, other times bad?
>> 
>> Did you modprobe using some options?
> 
> My netperf results (3 sec samples) are:
> 
> TCP_MAERTS Test:  13.60 14.41 16.05 15.01 14.70 15.36 14.72 15.07 12.37 11.01
> Results: max 16.05, min 11.01. Mean 14.23(1.44)
> 
> TCP_STREAM Test:   3.00  1.89  1.23  2.12  0.91  1.59  1.46  0.71  1.99  2.12
> Results: max  3.00, min  0.71. Mean  1.70(0.64)
> 
> As you can see, RX is OK, but TX is quite low.
> 
> I will run the same test with brcmsmac later. Their damned Kconfig won't let me build both b43 and brcmsmac at the same time.
Larry, Rafal, bad news.

After bisecting it turned out that I was using brcmsmac in 3.0.0-wl and b43 with all the others (unfortunately :-( ).

Bottom line: I'm always experiencing very low power when using b43, with all kernel versions. Switching to 3.2.0 and changing firmware accordingly does not solve the problem. Transmission performance using iperf is really low with b43 from a 43224, the emitted power is too low and the majority of packets are received corrupt. For this reason minstrel selects 1Mb/s... and throughput falls down. I tried to manually force other rates at the firmware level but it's even worse.

Note the as soon as I switch to brcmsmac tx power is correctly set.

Larry: just to double check, I'm using the device below, is like yours? Photograph here: http://www.ing.unibs.it/~gringoli/foto.JPG

Many thanks,
-Francesco

[ 5087.800398] b43-phy8: Broadcom 43224 WLAN found (core revision 23)
[ 5087.800803] b43-phy8 debug: Found PHY: Analog 8, Type 4, Revision 6
[ 5087.800819] b43-phy8 debug: Found Radio: Manuf 0x17F, Version 0x2056, Revision 11

02:00.0 0280: 14e4:4353 (rev 01)
	Subsystem: 103c:1509
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort+ <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory@e0100000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: bcma-pci-bridge
	Kernel modules: bcma



> 
> Larry
> 
> 
> 

low throughputs with 14e4:4353

[Rafał Miłecki]

W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
<zajec5@gmail.com> napisa?:
> I'll give it a rest and will try in next days again.

It really seems it's something spur avoidance related (and so most
probably CC PLL related). After applying my patch implementing SPUR
avoidance, card stops receiving anything. I'll dig more around it.

-- 
Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

hi rafal

thanks. 

Inviato da iPhone

Il giorno Dec 5, 2011, alle ore 9:39 PM, Rafa? Mi?ecki <zajec5@gmail.com> ha scritto:

> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
> <zajec5@gmail.com> napisa?:
>> I'll give it a rest and will try in next days again.
> 
> It really seems it's something spur avoidance related (and so most
> probably CC PLL related). After applying my patch implementing SPUR
> avoidance, card stops receiving anything. I'll dig more around it.
> 
> -- 
> Rafa?

low throughputs with 14e4:4353

[Rafał Miłecki]

W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
> <zajec5@gmail.com> napisa?:
>> I'll give it a rest and will try in next days again.
>
> It really seems it's something spur avoidance related (and so most
> probably CC PLL related). After applying my patch implementing SPUR
> avoidance, card stops receiving anything. I'll dig more around it.

I've found bug in my implementation and fixed it. Today evening I'll
test if my patch fixes performance anyhow (I need physical access).

Larry: I've found two mistakes/lacks in the specs.
1) http://bcm-v4.sipsolutions.net/802.11/PmuSpurAvoid
This routine ignores my BCM43224. However from wl MMIO dump I can see
it should make some ops on my chip. Example log from wl:
write32 0xfaaff660 <- 0x00000000
write32 0xfaaff664 <- 0x11100010
write32 0xfaaff660 <- 0x00000001
write32 0xfaaff664 <- 0x000c0c06
write32 0xfaaff660 <- 0x00000002
write32 0xfaaff664 <- 0x03000a08
write32 0xfaaff660 <- 0x00000003
write32 0xfaaff664 <- 0x00000000
write32 0xfaaff660 <- 0x00000004
write32 0xfaaff664 <- 0x200005c0
write32 0xfaaff660 <- 0x00000005
write32 0xfaaff664 <- 0x88888815
 read32 0xfaaff600 -> 0x00000381
write32 0xfaaff600 <- 0x00000781

2) http://bcm-v4.sipsolutions.net/802.11/PHY/N/ChanspecSetup
There is condition: "If the chip is greater than 0x4349 and less then 0x4356".
This should but applied "too"/"instead" for BCM43224@least. wl
executes that commands for my BCM43224:
write16 0xfaafc62e <- 0x8889
write16 0xfaafc630 <- 0x0008

-- 
Rafa?

low throughputs with 14e4:4353

[Larry Finger]

On 12/07/2011 06:01 AM, Rafa? Mi?ecki wrote:
> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki<zajec5@gmail.com>  napisa?:
>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>> <zajec5@gmail.com>  napisa?:
>>> I'll give it a rest and will try in next days again.
>>
>> It really seems it's something spur avoidance related (and so most
>> probably CC PLL related). After applying my patch implementing SPUR
>> avoidance, card stops receiving anything. I'll dig more around it.
>
> I've found bug in my implementation and fixed it. Today evening I'll
> test if my patch fixes performance anyhow (I need physical access).
>
> Larry: I've found two mistakes/lacks in the specs.
> 1) http://bcm-v4.sipsolutions.net/802.11/PmuSpurAvoid
> This routine ignores my BCM43224. However from wl MMIO dump I can see
> it should make some ops on my chip. Example log from wl:
> write32 0xfaaff660<- 0x00000000
> write32 0xfaaff664<- 0x11100010
> write32 0xfaaff660<- 0x00000001
> write32 0xfaaff664<- 0x000c0c06
> write32 0xfaaff660<- 0x00000002
> write32 0xfaaff664<- 0x03000a08
> write32 0xfaaff660<- 0x00000003
> write32 0xfaaff664<- 0x00000000
> write32 0xfaaff660<- 0x00000004
> write32 0xfaaff664<- 0x200005c0
> write32 0xfaaff660<- 0x00000005
> write32 0xfaaff664<- 0x88888815
>   read32 0xfaaff600 ->  0x00000381
> write32 0xfaaff600<- 0x00000781
>
> 2) http://bcm-v4.sipsolutions.net/802.11/PHY/N/ChanspecSetup
> There is condition: "If the chip is greater than 0x4349 and less then 0x4356".
> This should but applied "too"/"instead" for BCM43224 at least. wl
> executes that commands for my BCM43224:
> write16 0xfaafc62e<- 0x8889
> write16 0xfaafc630<- 0x0008

Both places should have used chip ID of 43224 and 43225 (at least). The second 
also needs 43222 and probably 43228 (I'm still checking that.) The first may 
also need 43222 and 43228.

Larry

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:

> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>> <zajec5@gmail.com> napisa?:
>>> I'll give it a rest and will try in next days again.
>> 
>> It really seems it's something spur avoidance related (and so most
>> probably CC PLL related). After applying my patch implementing SPUR
>> avoidance, card stops receiving anything. I'll dig more around it.
> 
> I've found bug in my implementation and fixed it. Today evening I'll
> test if my patch fixes performance anyhow (I need physical access).
Rafal,

I did some mmio traces and checked what happens when changing txpower.

1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.

2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.

Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.

Hope can help.
-Francesco

low throughputs with 14e4:4353

[Rafał Miłecki]

W dniu 8 grudnia 2011 10:21 u?ytkownik
<francesco.gringoli@ing.unibs.it> napisa?:
>
> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>
>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>> <zajec5@gmail.com> napisa?:
>>>> I'll give it a rest and will try in next days again.
>>>
>>> It really seems it's something spur avoidance related (and so most
>>> probably CC PLL related). After applying my patch implementing SPUR
>>> avoidance, card stops receiving anything. I'll dig more around it.
>>
>> I've found bug in my implementation and fixed it. Today evening I'll
>> test if my patch fixes performance anyhow (I need physical access).
> Rafal,
>
> I did some mmio traces and checked what happens when changing txpower.
>
> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>
> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>
> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.

I can see a lot of differences between wl and b43, a lot to validate&test.

Do you have some magic scripts for parsing MMIO dumps? I hope you do,
otherwise it's impossible to analyze that ;)

You can try adding
nphy->txpwrctrl = true;
in function b43_nphy_op_prepare_structs if you wish test something
right now. I've noticed this missing part today morning, but won't
able to test until evening.

-- 
Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Dec 8, 2011, at 10:34 AM, Rafa? Mi?ecki wrote:

> W dniu 8 grudnia 2011 10:21 u?ytkownik
> <francesco.gringoli@ing.unibs.it> napisa?:
>> 
>> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>> 
>>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>>> <zajec5@gmail.com> napisa?:
>>>>> I'll give it a rest and will try in next days again.
>>>> 
>>>> It really seems it's something spur avoidance related (and so most
>>>> probably CC PLL related). After applying my patch implementing SPUR
>>>> avoidance, card stops receiving anything. I'll dig more around it.
>>> 
>>> I've found bug in my implementation and fixed it. Today evening I'll
>>> test if my patch fixes performance anyhow (I need physical access).
>> Rafal,
>> 
>> I did some mmio traces and checked what happens when changing txpower.
>> 
>> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>> 
>> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>> 
>> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.
> 
> I can see a lot of differences between wl and b43, a lot to validate&test.
> 
> Do you have some magic scripts for parsing MMIO dumps? I hope you do,
> otherwise it's impossible to analyze that ;)
No, I don't have yet. But I can ask some wizard to write some perl stuff. I will report his answer later ;-)

> You can try adding
> nphy->txpwrctrl = true;
> in function b43_nphy_op_prepare_structs if you wish test something
> right now. I've noticed this missing part today morning, but won't
> able to test until evening.
No improvement. But I believe that when that is set up it's the firmware to change the power levels but the firmware does not change the tables. Maybe it does by rewriting the power mask in the tx transmission control field overwriting what written by the kernel driver.

-Francesco

> 
> -- 
> Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Dec 8, 2011, at 10:34 AM, Rafa? Mi?ecki wrote:

> W dniu 8 grudnia 2011 10:21 u?ytkownik
> <francesco.gringoli@ing.unibs.it> napisa?:
>> 
>> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>> 
>>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>>> <zajec5@gmail.com> napisa?:
>>>>> I'll give it a rest and will try in next days again.
>>>> 
>>>> It really seems it's something spur avoidance related (and so most
>>>> probably CC PLL related). After applying my patch implementing SPUR
>>>> avoidance, card stops receiving anything. I'll dig more around it.
>>> 
>>> I've found bug in my implementation and fixed it. Today evening I'll
>>> test if my patch fixes performance anyhow (I need physical access).
>> Rafal,
>> 
>> I did some mmio traces and checked what happens when changing txpower.
>> 
>> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>> 
>> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>> 
>> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.
> 
> I can see a lot of differences between wl and b43, a lot to validate&test.
> 
> Do you have some magic scripts for parsing MMIO dumps? I hope you do,
> otherwise it's impossible to analyze that ;)
Hi Rafal,

my dumb email filter moves messages to b43-dev if I'm not explicitly in To: so I missed your script sharing and some messages from Larry. Ok, I modified the rules :-)

But before that I wrote a short perl script which helped me finding the following (if you want to give it a try it's here http://www.ing.unibs.it/~gringoli/b43_parsemmio.pl ).

So I traced what changes when I set the power to either 5/10 or 15: the only different setting in phy regs is for phy reg 0x01EA where the driver writes the following values according to power level (5, 10 or 15):

5	=>	phy(0x01EA) <= 0x2020
10	=>	phy(0x01EA) <= 0x2828
15	=>	phy(0x01EA) <= 0x3C3C

Then the driver refreshes tables at address 0x6800, 0x6840, 0x6C00 and 0x6C40, you can find the human readable forms for the 5/10/15 cases here

http://www.ing.unibs.it/~gringoli/table_set5
http://www.ing.unibs.it/~gringoli/table_set10
http://www.ing.unibs.it/~gringoli/table_set15

You see: for 5 and 10 the tables are identical, while for 15 some values are different. It seems also that tables@6840 and 6C40 are shorter than that uploaded by b43 (84 values instead of 128).

With the b43 driver if I manually force from the firmware the power level to either 0x2020 or 0x2828 I get increasing rates (up to ~ 3Mb/s) and everything works. If instead I set greater values I get only PHY transmission errors and no packet is ever transmitted.

Cheers,
-Francesco

P.S. I see that the Broadcom driver continues uploading values in tables for a while, after that everything seems to be "stable" for a while and no more values are uploaded. It can take 10 minutes to stabilize...

> You can try adding
> nphy->txpwrctrl = true;
> in function b43_nphy_op_prepare_structs if you wish test something
> right now. I've noticed this missing part today morning, but won't
> able to test until evening.
> 
> -- 
> Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Dec 8, 2011, at 10:34 AM, Rafa? Mi?ecki wrote:

> W dniu 8 grudnia 2011 10:21 u?ytkownik
> <francesco.gringoli@ing.unibs.it> napisa?:
>> 
>> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>> 
>>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>>> <zajec5@gmail.com> napisa?:
>>>>> I'll give it a rest and will try in next days again.
>>>> 
>>>> It really seems it's something spur avoidance related (and so most
>>>> probably CC PLL related). After applying my patch implementing SPUR
>>>> avoidance, card stops receiving anything. I'll dig more around it.
>>> 
>>> I've found bug in my implementation and fixed it. Today evening I'll
>>> test if my patch fixes performance anyhow (I need physical access).
>> Rafal,
>> 
>> I did some mmio traces and checked what happens when changing txpower.
>> 
>> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>> 
>> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>> 
>> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.
> 
> I can see a lot of differences between wl and b43, a lot to validate&test.
> 
> Do you have some magic scripts for parsing MMIO dumps? I hope you do,
> otherwise it's impossible to analyze that ;)
> 
> You can try adding
> nphy->txpwrctrl = true;
> in function b43_nphy_op_prepare_structs if you wish test something
> right now. I've noticed this missing part today morning, but won't
> able to test until evening.
> 
Hi Rafal,

great! I applied all the last patches you sent and the throughput now grows during an iperf experiment.

Unfortunately, if to a given AP I can get up to 17-18Mb/s from a 4318, my 43224 never exceeds 5Mb/s :-(

Are you experiencing something similar?

Many thanks,
-Francesco

low throughputs with 14e4:4353

[Rafał Miłecki]

W dniu 14 grudnia 2011 18:02 u?ytkownik
<francesco.gringoli@ing.unibs.it> napisa?:
> On Dec 8, 2011, at 10:34 AM, Rafa? Mi?ecki wrote:
>
>> W dniu 8 grudnia 2011 10:21 u?ytkownik
>> <francesco.gringoli@ing.unibs.it> napisa?:
>>>
>>> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>>>
>>>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>>>> <zajec5@gmail.com> napisa?:
>>>>>> I'll give it a rest and will try in next days again.
>>>>>
>>>>> It really seems it's something spur avoidance related (and so most
>>>>> probably CC PLL related). After applying my patch implementing SPUR
>>>>> avoidance, card stops receiving anything. I'll dig more around it.
>>>>
>>>> I've found bug in my implementation and fixed it. Today evening I'll
>>>> test if my patch fixes performance anyhow (I need physical access).
>>> Rafal,
>>>
>>> I did some mmio traces and checked what happens when changing txpower.
>>>
>>> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>>>
>>> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>>>
>>> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.
>>
>> I can see a lot of differences between wl and b43, a lot to validate&test.
>>
>> Do you have some magic scripts for parsing MMIO dumps? I hope you do,
>> otherwise it's impossible to analyze that ;)
>>
>> You can try adding
>> nphy->txpwrctrl = true;
>> in function b43_nphy_op_prepare_structs if you wish test something
>> right now. I've noticed this missing part today morning, but won't
>> able to test until evening.
>>
> Hi Rafal,
>
> great! I applied all the last patches you sent and the throughput now grows during an iperf experiment.
>
> Unfortunately, if to a given AP I can get up to 17-18Mb/s from a 4318, my 43224 never exceeds 5Mb/s :-(
>
> Are you experiencing something similar?

I can achieve about 6-8 Mb/s on my BCM43224.

If you take a look at
http://bcm-v4.sipsolutions.net/RecentChanges
you can see Larry updated/filled a lot of routines recently. Most of
them TX related, some writing tables and I think one of them touches
0x1ea register. So give me few more days, I'll publish more patches
and the we will finally do some real tests:)

-- 
Rafa?

low throughputs with 14e4:4353

[francesco.gringoli at ing.unibs.it]

On Dec 14, 2011, at 7:04 PM, Rafa? Mi?ecki wrote:

> W dniu 14 grudnia 2011 18:02 u?ytkownik
> <francesco.gringoli@ing.unibs.it> napisa?:
>> On Dec 8, 2011, at 10:34 AM, Rafa? Mi?ecki wrote:
>> 
>>> W dniu 8 grudnia 2011 10:21 u?ytkownik
>>> <francesco.gringoli@ing.unibs.it> napisa?:
>>>> 
>>>> On Dec 7, 2011, at 1:01 PM, Rafa? Mi?ecki wrote:
>>>> 
>>>>> W dniu 5 grudnia 2011 21:39 u?ytkownik Rafa? Mi?ecki <zajec5@gmail.com> napisa?:
>>>>>> W dniu 29 listopada 2011 22:36 u?ytkownik Rafa? Mi?ecki
>>>>>> <zajec5@gmail.com> napisa?:
>>>>>>> I'll give it a rest and will try in next days again.
>>>>>> 
>>>>>> It really seems it's something spur avoidance related (and so most
>>>>>> probably CC PLL related). After applying my patch implementing SPUR
>>>>>> avoidance, card stops receiving anything. I'll dig more around it.
>>>>> 
>>>>> I've found bug in my implementation and fixed it. Today evening I'll
>>>>> test if my patch fixes performance anyhow (I need physical access).
>>>> Rafal,
>>>> 
>>>> I did some mmio traces and checked what happens when changing txpower.
>>>> 
>>>> 1) values in N-PHY tables 0x1A and 0x1B are changed, e.g., for txpower 5 and txpower 10 they are the same, for txpower 15 they are different so I guess there exist thresholds. Unfortunately I don't even know what these tables are.
>>>> 
>>>> 2) value in PHY register 0x1ea is changed according to the configured power value. As I can read in specs this is the TX power control target power for both radios: e.g., for txpower 5 => 0x2020, for txpower 10 => 0x2c2c, for txpower 15 => 0x3c3c.
>>>> 
>>>> Then I switched to b43 and load a custom firmware to analyze how register 0x1ea is setup and it holds always 0x0000. I forced it to be 0x2c2c and magically the throughput increased to ~ 3Mb/s. Unfortunately when I try 0x3c3c (corresponding to txpower 15) I get only phy-transmission errors.
>>> 
>>> I can see a lot of differences between wl and b43, a lot to validate&test.
>>> 
>>> Do you have some magic scripts for parsing MMIO dumps? I hope you do,
>>> otherwise it's impossible to analyze that ;)
>>> 
>>> You can try adding
>>> nphy->txpwrctrl = true;
>>> in function b43_nphy_op_prepare_structs if you wish test something
>>> right now. I've noticed this missing part today morning, but won't
>>> able to test until evening.
>>> 
>> Hi Rafal,
>> 
>> great! I applied all the last patches you sent and the throughput now grows during an iperf experiment.
>> 
>> Unfortunately, if to a given AP I can get up to 17-18Mb/s from a 4318, my 43224 never exceeds 5Mb/s :-(
>> 
>> Are you experiencing something similar?
> 
> I can achieve about 6-8 Mb/s on my BCM43224.
> 
> If you take a look at
> http://bcm-v4.sipsolutions.net/RecentChanges
> you can see Larry updated/filled a lot of routines recently. Most of
> them TX related, some writing tables and I think one of them touches
> 0x1ea register. So give me few more days, I'll publish more patches
> and the we will finally do some real tests:)
I really appreciate your efforts, guys!

Just to add another bit of information: though the link is very good (54Mb/s is always selected by the 4318 card), with the 43224 48 and 54Mb/s frames are likely to fail, while 36Mb/s is almost 100% succeeding.

-Francesco

> 
> -- 
> Rafa?