linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming
@ 2017-05-24 11:33 Jérôme Carretero
  2017-06-01  6:37 ` Jörg Krause
  0 siblings, 1 reply; 4+ messages in thread
From: Jérôme Carretero @ 2017-05-24 11:33 UTC (permalink / raw)
  To: Franky Lin, Wright Feng; +Cc: Arend van Spriel, linux-wireless

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming
  2017-05-24 11:33 brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming Jérôme Carretero
@ 2017-06-01  6:37 ` Jörg Krause
  2017-08-18 11:50   ` Fabio Estevam
  0 siblings, 1 reply; 4+ messages in thread
From: Jörg Krause @ 2017-06-01  6:37 UTC (permalink / raw)
  To: Jérôme Carretero, Franky Lin, Wright Feng
  Cc: Arend van Spriel, linux-wireless

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming
  2017-06-01  6:37 ` Jörg Krause
@ 2017-08-18 11:50   ` Fabio Estevam
  2017-08-21 18:09     ` Jörg Krause
  0 siblings, 1 reply; 4+ messages in thread
From: Fabio Estevam @ 2017-08-18 11:50 UTC (permalink / raw)
  To: Jörg Krause
  Cc: Jérôme Carretero, Franky Lin, Wright Feng,
	Arend van Spriel, linux-wireless

Hi J=C3=B6rg,

On Thu, Jun 1, 2017 at 3:37 AM, J=C3=B6rg Krause <joerg.krause@embedded.roc=
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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming
  2017-08-18 11:50   ` Fabio Estevam
@ 2017-08-21 18:09     ` Jörg Krause
  0 siblings, 0 replies; 4+ messages in thread
From: Jörg Krause @ 2017-08-21 18:09 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Jérôme Carretero, Franky Lin, Wright Feng,
	Arend van Spriel, linux-wireless

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 <joerg.krause@embedded.rocks> 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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2017-08-21 18:17 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-05-24 11:33 brcmfmac experiment for a specific use case - tx throughput maximization for slow CPU with glomming Jérôme Carretero
2017-06-01  6:37 ` Jörg Krause
2017-08-18 11:50   ` Fabio Estevam
2017-08-21 18:09     ` Jörg Krause

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).