Hi,
I've crippled a Raspberry Pi 3 (1 core, 200 MHz) and observed that the
glomming feature has a definite impact on TX performance, but it looks
like at this CPU frequency, the work queue is solicited "too often"
by brcmf_sdio_trigger_dpc() and glomming is only doing 4 packets at
once, resulting in maybe a sub-optimal throughput.
I have a vague idea that deliberately delaying the transmissions so as
to wait for either a small timeout, or the glomming level has been
reached, would be something worth exploring.
But I haven't spent a long time looking at the driver.
I'm just soliciting your advice at this point, I'll do some experiments
also.
Best regards,
--=20
J=C3=A9r=C3=B4me
Hi Jérôme,
On Wed, 2017-05-24 at 07:33 -0400, Jérôme Carretero wrote:
> Hi,
>
>
> I've crippled a Raspberry Pi 3 (1 core, 200 MHz) and observed that the
> glomming feature has a definite impact on TX performance, but it looks
> like at this CPU frequency, the work queue is solicited "too often"
> by brcmf_sdio_trigger_dpc() and glomming is only doing 4 packets at
> once, resulting in maybe a sub-optimal throughput.
I'm experiencing low throughput with a BCM43362 wifi chip attached via
SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
is still below the throughput I get for the Cubietruck.
>
> I have a vague idea that deliberately delaying the transmissions so as
> to wait for either a small timeout, or the glomming level has been
> reached, would be something worth exploring.
> But I haven't spent a long time looking at the driver.
If you are in need for any testing I'm willing to help!
[1] https://www.spinics.net/lists/linux-wireless/msg153257.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-October/
461137.html
Jörg
Hi J=C3=B6rg,
On Thu, Jun 1, 2017 at 3:37 AM, J=C3=B6rg Krause <[email protected]=
ks> wrote:
> I'm experiencing low throughput with a BCM43362 wifi chip attached via
> SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
> getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
> is still below the throughput I get for the Cubietruck.
Does it help if you disable CONFIG_PROVE_LOCKING?
--- a/arch/arm/configs/mxs_defconfig
+++ b/arch/arm/configs/mxs_defconfig
@@ -175,7 +175,6 @@ CONFIG_MAGIC_SYSRQ=3Dy
CONFIG_DEBUG_KERNEL=3Dy
CONFIG_LOCKUP_DETECTOR=3Dy
CONFIG_TIMER_STATS=3Dy
-CONFIG_PROVE_LOCKING=3Dy
CONFIG_BLK_DEV_IO_TRACE=3Dy
CONFIG_STRICT_DEVMEM=3Dy
CONFIG_DEBUG_USER=3Dy
Hi Fabio,
On Fri, 2017-08-18 at 08:50 -0300, Fabio Estevam wrote:
> Hi Jörg,
>
> On Thu, Jun 1, 2017 at 3:37 AM, Jörg Krause <[email protected]> wrote:
>
> > I'm experiencing low throughput with a BCM43362 wifi chip attached via
> > SDIO to an i.MX28 [1,2]. After disabling some Kernel debug features I'm
> > getting now a TCP throughput of 12.5 Mbps for the wifi interface, which
> > is still below the throughput I get for the Cubietruck.
>
> Does it help if you disable CONFIG_PROVE_LOCKING?
No, it does not. I've disabled all settings in "Lock Debugging", but
the TCP throughput is still at ~12.5 Mpbs.
> --- a/arch/arm/configs/mxs_defconfig
> +++ b/arch/arm/configs/mxs_defconfig
> @@ -175,7 +175,6 @@ CONFIG_MAGIC_SYSRQ=y
> CONFIG_DEBUG_KERNEL=y
> CONFIG_LOCKUP_DETECTOR=y
> CONFIG_TIMER_STATS=y
> -CONFIG_PROVE_LOCKING=y
> CONFIG_BLK_DEV_IO_TRACE=y
> CONFIG_STRICT_DEVMEM=y
> CONFIG_DEBUG_USER=y