Skip to contentSkip to conversation

poor performance with W2CBW003 (Marvell 8686)

DISCUSSION Andreas Kemnade 4 participants 13 messages Jun 9, 2012 – Oct 29, 2012

lore
Share & tools
lore
#0 lore raw

Hi,

on the GTA04 (www.gta04.org)
which has a W2CBW003 chip for wifi connected to a DM3730CBP CPU. data rates are quite low using the libertas driver from kernel 3.2-3.4
(https://github.com/neilbrown/gta04/branches)
even near an accesspoint. That seems not depend on the encryption settings. Rates are around 100KByte/s. iwconfig shows 5.5Mb/s if it is not connected to an accesspoint with specially configured rates (but still the throughput is low).

In contrary data rates are high (>1MByte/s) with a kernel based on the 2.6.32 BeagleBoard XM hw-validation kernel
https://github.com/goldelico/gta04-kernel
That behaviour was reported by several people.

I tried also the libertas-tf driver with kernel 3.2 using the instructions here:
http://corysohrakoff.wordpress.com/2011/09/13/enabling-wifi-ap-mode-on-a-gumstix-overo/
That was also slow.

Any hints?

Greetings
Andreas Kemnade

#1 lore raw
Quoted 16 lines · Andreas Kemnade

Hi,

on the GTA04 (www.gta04.org)
which has a W2CBW003 chip for wifi connected to a DM3730CBP CPU. data rates are quite low using the libertas driver from kernel 3.2-3.4
(https://github.com/neilbrown/gta04/branches)
even near an accesspoint. That seems not depend on the encryption settings. Rates are around 100KByte/s. iwconfig shows 5.5Mb/s if it is not connected to an accesspoint with specially configured rates (but still the throughput is low).

In contrary data rates are high (>1MByte/s) with a kernel based on the 2.6.32 BeagleBoard XM hw-validation kernel
https://github.com/goldelico/gta04-kernel
That behaviour was reported by several people.

Quoted 6 lines

I tried also the libertas-tf driver with kernel 3.2 using the instructions here:
http://corysohrakoff.wordpress.com/2011/09/13/enabling-wifi-ap-mode-on-a-gumstix-overo/
That was also slow.

Any hints?

GSPI or SDIO? What SD host controller? Does the controller support 4-bit mode correctly? What block sizes does it support? Most often the issue is with crappy host controllers that need workarounds or quirks to correctly support the higher speeds that the driver can do. The benchmark I always used was that on a laptop with a Ricoh SD controller, I could easily pull megabits per second even 15 feet away.

(that's not to say there aren't inefficiencies in the driver, just that we know that given a good SDHC and a good SDHC driver, that the libertas driver itself is not the bottleneck).

Dan

#2 lore raw

Hi,

Quoted 17 lines · Dan Williams
Quoted 16 lines · Andreas Kemnade

Hi,

on the GTA04 (www.gta04.org)
which has a W2CBW003 chip for wifi connected to a DM3730CBP CPU. data rates are quite low using the libertas driver from kernel 3.2-3.4
(https://github.com/neilbrown/gta04/branches)
even near an accesspoint. That seems not depend on the encryption settings. Rates are around 100KByte/s. iwconfig shows 5.5Mb/s if it is not connected to an accesspoint with specially configured rates (but still the throughput is low).

In contrary data rates are high (>1MByte/s) with a kernel based on the 2.6.32 BeagleBoard XM hw-validation kernel
https://github.com/goldelico/gta04-kernel
That behaviour was reported by several people.

Quoted 8 lines
Quoted 6 lines

I tried also the libertas-tf driver with kernel 3.2 using the instructions here:
http://corysohrakoff.wordpress.com/2011/09/13/enabling-wifi-ap-mode-on-a-gumstix-overo/
That was also slow.

Any hints?

GSPI or SDIO? What SD host controller? Does the controller support

It is the host controller integrated into the SoC (the DM3730 from TI). There is
a level shifter (the 74avca406) in between.

Quoted 6 lines

4-bit mode correctly? What block sizes does it support? Most often the issue is with crappy host controllers that need workarounds or quirks to correctly support the higher speeds that the driver can do. The benchmark I always used was that on a laptop with a Ricoh SD controller, I could easily pull megabits per second even 15 feet away.

4 bit is supported.
The hardware does not impose unresolvable limitations, the 2.6.32 kernel gives high performance. But since that kernel is not mainstream, it is very hard to find out which patch gives the slowdown. git bisect is not very useful in that situation.
SD memory card reading speed is always ok (on another of the integrated sd host controllers).

I'm citing from the
AM/DM37x Multimedia Device
Silicon Revision 1.x
Version O
Technical Reference Manual from TI page 3396
from http://www.ti.com/product/dm3730
here:

Quoted 26 lines

The known limitations are as follows:
· No built-in hardware support for error correction codes (ECC). See the Multimedia Card System
Specification, v4.2, and the SD Memory Card Specifications, v2.0,
for details about ECC.
· The maximum block size defined in the SD Memory Card Specifications, v2.0, that the host driver can
read and write to the buffer in the host controller is 2048 bytes.
MMC supports a maximum block size
of 1024 bytes. Up to 512 byte transfers, the buffer in MMC is
considered as a double buffering with
ping-pong management; half of the buffer can be written while the
other part is read. For 512 to 1024
byte transfers, the entire buffer is dedicated to the transfer (read
only or write only).

The differences between the MMC/SD/SDIO host controllers and a standard SD host controller are
defined by the SD Card Specification, Part A2, SD Host Controller Standard Specification, v1.00, as
follows:
· The MMC/SD/SDIO host controllers support MMC cards.
· The MMC/SD/SDIO host controller is defined as a DMA slave device. A standard SD host controller is
defined as a DMA master controller that can start and stop a DMA

Quoted 8 lines

transfer. MMC/SD/SDIO host
controllers support DMA transfers through slave DMA requests.
· The clock divider in MMC/SD/SDIO host controller supports a wider range of frequency than specified
in the SD Memory Card Specifications, v2.0. The MMC/SD/SDIO host
controller supports odd and
even clock ratio.
· The MMC/SD/SDIO host controller supports configurable busy time-out.

Maybe you can name the limitation which might be problematic here.

Greetings
Andreas Kemnade

#3 lore raw
Quoted 11 lines

4 bit is supported.
The hardware does not impose unresolvable limitations, the 2.6.32 kernel
gives high performance. But since that kernel is not mainstream, it is
very hard to find out which patch gives the slowdown. git bisect
is not very useful in that situation.
SD memory card reading speed is always ok (on another of the integrated
sd host controllers).

Have you tested receive throughput? Any difference between TX and Rx throughput?

#4 lore raw

Hi,

Quoted 12 lines · On Wed, 13 Jun 2012 10:06:54 -0700 (PDT) hong zhang <[email protected]>…
Quoted 11 lines

4 bit is supported.
The hardware does not impose unresolvable limitations, the 2.6.32 kernel
gives high performance. But since that kernel is not mainstream, it is
very hard to find out which patch gives the slowdown. git bisect
is not very useful in that situation.
SD memory card reading speed is always ok (on another of the integrated
sd host controllers).

Quoted 2 lines

Have you tested receive throughput? Any difference between TX and Rx throughput?

I tested both.
No significant difference with 3.x.

Greetings
Andreas Kemnade

#5 lore raw

You have to identify problem caused by
SDIO host controller or wifi driver.

If driver is working well in x86 with Roch SDIO, that means wifi driver is ok.

You have to find out
1. SDIO interface if using Interrupt or PIO
2. 1 bit or 4 bit
3. TI BSP SDIO controller

Quoted 36 lines · Andreas Kemnade

From: Andreas Kemnade <[email protected]>
Subject: Re: poor performance with W2CBW003 (Marvell 8686)
To: "hong zhang" <[email protected]>
Cc: "Dan Williams" <[email protected]>, [email protected], [email protected], [email protected]
Date: Wednesday, June 13, 2012, 12:42 PM
Hi,

Quoted 2 lines · On Wed, 13 Jun 2012 10:06:54 -0700 (PDT) hong zhang <[email protected]>…
Quoted 2 lines

4 bit is supported.
The hardware does not impose unresolvable

limitations, the

Quoted 2 lines
Quoted 2 lines

2.6.32 kernel
gives high performance. But since that kernel is

not

Quoted 2 lines
Quoted 2 lines

mainstream, it is
very hard to find out which patch gives the

slowdown. git

Quoted 3 lines
Quoted 3 lines

bisect
is not very useful in that situation.
SD memory card reading speed is always ok (on

another of the

Quoted 4 lines
Quoted 2 lines

integrated
sd host controllers).

Have you tested receive throughput? Any difference

between TX and Rx throughput?

Quoted 1 line

I tested both.
No significant difference with 3.x.

Greetings
Andreas Kemnade

#6 lore raw

Hi,

Quoted 7 lines · On Wed, 13 Jun 2012 11:39:08 -0700 (PDT) hong zhang <[email protected]>…

You have to identify problem caused by
SDIO host controller or wifi driver.

If driver is working well in x86 with Roch SDIO, that means wifi driver is ok.

You have to find out
1. SDIO interface if using Interrupt or PIO

Hmm, very interesting point, of course, there are interrupts. But after reading the commit logs in the patched 2.6.32 kernel I see there is a patch enabling asynchronous *sdio* interrupts. That looks clearly suspicious.

Quoted 1 line

2. 1 bit or 4 bit

Hmm, 4bit.

Greetings
Andreas Kemnade

#7 lore raw

bit mode and interrupt or PIO are configured in SDIO hoster side. Not in driver side.

Quoted 34 lines · Andreas Kemnade

From: Andreas Kemnade <[email protected]>
Subject: Re: poor performance with W2CBW003 (Marvell 8686)
To: "hong zhang" <[email protected]>
Cc: "Dan Williams" <[email protected]>, [email protected], [email protected], [email protected]
Date: Thursday, June 14, 2012, 12:45 AM
Hi,

Quoted 4 lines · On Wed, 13 Jun 2012 11:39:08 -0700 (PDT) hong zhang <[email protected]>…

You have to identify problem caused by
SDIO host controller or wifi driver.

If driver is working well in x86 with Roch SDIO, that

means wifi driver is ok.

Quoted 3 lines

You have to find out
1. SDIO interface if using Interrupt or PIO

Hmm, very interesting point, of course, there are interrupts. But after reading
the commit logs in the patched 2.6.32 kernel I see there is a patch enabling
asynchronous *sdio* interrupts. That looks clearly suspicious.

Quoted 1 line

2. 1 bit or 4 bit

Hmm, 4bit.

Greetings
Andreas Kemnade

#8 lore raw

Actually, you have to check SDIO driver done by TI. There are 5 SDIO pins need to check. 4 data pins and one clock pin.

Double check the SDIO pins muxs and clock rate using TI reference manual.

By performance issues.
1. bit modes 1 or 4
2. interrupt/PIO
3. SDIO clock rate

Command 52 and 53 are important.
See this link for SDIO reference.
http://www.sandisk.com/Assets/File/OEM/Manuals/SD_SDIO_specsv1.pdf

Quoted 57 lines · hong zhang

From: hong zhang <[email protected]>
Subject: Re: poor performance with W2CBW003 (Marvell 8686)
To: "Andreas Kemnade" <[email protected]>
Cc: "Dan Williams" <[email protected]>, [email protected], [email protected], [email protected]
Date: Thursday, June 14, 2012, 11:11 AM
bit mode and interrupt or PIO are
configured in SDIO hoster side.
Not in driver side.

--- On Thu, 6/14/12, Andreas Kemnade <[email protected]>

Quoted 2 lines · wrote:

From: Andreas Kemnade <[email protected]>
Subject: Re: poor performance with W2CBW003 (Marvell

8686)

Quoted 2 lines

To: "hong zhang" <[email protected]>
Cc: "Dan Williams" <[email protected]>,

[email protected],
[email protected], [email protected]

Quoted 11 lines

Date: Thursday, June 14, 2012, 12:45 AM Hi,

Quoted 4 lines · On Wed, 13 Jun 2012 11:39:08 -0700 (PDT) hong zhang <[email protected]>…

You have to identify problem caused by
SDIO host controller or wifi driver.

If driver is working well in x86 with Roch SDIO,

that

Quoted 8 lines

means wifi driver is ok.

Quoted 3 lines

You have to find out
1. SDIO interface if using Interrupt or PIO

Hmm, very interesting point, of course, there are interrupts. But after reading
the commit logs in the patched 2.6.32 kernel I see

there is

Quoted 11 lines

a patch enabling
asynchronous *sdio* interrupts. That looks clearly suspicious.

Quoted 1 line

2. 1 bit or 4 bit

Hmm, 4bit.

Greetings
Andreas Kemnade

_______________________________________________
libertas-dev mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/libertas-dev

#9 lore raw
In reply to hong zhang

Hi,

Quoted 3 lines · On Thu, 14 Jun 2012 09:11:06 -0700 (PDT) hong zhang <[email protected]>…

bit mode and interrupt or PIO are configured in SDIO hoster side. Not in driver side.

yes, I wrote the last email just to say that I have found something to look at. That is of course in the host driver. So the thing I did was reading commit logs of the 2.6.32 kernel working well.

The only thing which puzzles me is the 5.5Mb/s data rate iwconfig shows. After playing with the host side driver, it also shows higher rates. But why does host driver affects *that* data rate of link qualitiy is good?

Thanks for all your ideas where to look at.

Greetings
Andreas Kemnade

#10 lore raw

To measure throughput, should not check iwconfig that is not accurate.

1. use wpa_supplicant to associate with AP
2. use iperf to measure throughput using UDP for Rx and Tx.

for SDIO host, command 52 doing register configuration. For rate, command 53 handles data rate. as sdio spec says clock rate is 0 to 100kHz means low speed mode. clock 0 to 25MHz means high speed mode.

Max throughput = clock-rate*num-of-data-line
for 4-bit, high clock,
max-throughput=25M*4=100Mbits/sec.
for 1-bit,low rate
max-throughput=100K*1=100Kbits/sec.

Quoted 33 lines · Andreas Kemnade

From: Andreas Kemnade <[email protected]>
Subject: Re: poor performance with W2CBW003 (Marvell 8686)
To: "hong zhang" <[email protected]>
Cc: "Dan Williams" <[email protected]>, [email protected], [email protected], [email protected]
Date: Friday, June 15, 2012, 1:18 AM
Hi,

Quoted 1 line · On Thu, 14 Jun 2012 09:11:06 -0700 (PDT) hong zhang <[email protected]>…

bit mode and interrupt or PIO are configured in SDIO

hoster side.

Quoted 2 lines

Not in driver side.

yes, I wrote the last email just to say that I have found something to look at.
That is of course in the host driver. So the thing I did was reading
commit logs of the 2.6.32 kernel working well.

The only thing which puzzles me is the 5.5Mb/s data rate iwconfig shows.
After playing with the host side driver, it also shows higher rates. But
why does host driver affects *that* data rate of link qualitiy is good?

Thanks for all your ideas where to look at.

Greetings
Andreas Kemnade

#11 lore raw
In reply to Andreas Kemnade
Quoted 8 lines · Andreas Kemnade

Hi,

Quoted 3 lines · On Thu, 14 Jun 2012 09:11:06 -0700 (PDT) hong zhang <[email protected]>…

bit mode and interrupt or PIO are configured in SDIO hoster side. Not in driver side.

Quoted 7 lines

yes, I wrote the last email just to say that I have found something to look at. That is of course in the host driver. So the thing I did was reading commit logs of the 2.6.32 kernel working well.

The only thing which puzzles me is the 5.5Mb/s data rate iwconfig shows. After playing with the host side driver, it also shows higher rates. But why does host driver affects *that* data rate of link qualitiy is good?

As said, that's the WiFi air link rate which is determined by the firmware based on the link quality with the AP, on things like RSSI, missed beacons, TX/RX errors, etc. That's not the SDIO data rate which is completely independent.

Dan

#12 lore raw

Hi Andreas,

I'm facing same issue on a 3.0.X kernel.
I've tried to merge some patches to support SDIO irq on 3.0 kernel but without success.

Interrupts are triggered and CPU load is greatly improved but performance is not here (1 Mbps up, 3 Mbps down)

Did you actually get a working "SDIO irq" patch on a recent kernel or did you finally use 2.6.32 one ?

Thanks,

Martin