Low network throughput on i.MX28

[Stefan Wahren]

Hi Jörg,

> Jörg Krause <joerg.krause at embedded.rocks> hat am 19. November 2016 um 00:49
> geschrieben:
> 
> 
> Hi all,
> 
> [snip]
> 
> I did some time measurements on the wifi, mmc and dma driver to compare
> the performance between the vendor and the mainline kernel. For this I
> toggled some GPIOs and measured the time difference with an osci. I
> started measuring the time before calling sdio_readsb() in the wifi
> driver [1] and stopped the time when the call returns. Note that the
> time was only measured for a packet length of 1536 bytes.
> 
> The vendor kernel took about 250 us to return whereas the mainline
> kernel took about 325 us. To investigate where this additional time
> comes from I divided the whole procedure into seperate parts and
> compared their time consumed.
> 
> I noticed that the mainline kernel does took much longer to return
> after the DMA request is done, signalled in this case by calling
> mxs_mmc_dma_irq_callback() [2] in the mxs-mmc driver. From here it
> takes about 150 us to get back to sdio_readsb().
> 
> An example for consuming much more time is the mainline mmc driver
> where it hangs in mmc_wait_done() [2] about 50 us just calling
> complete(), whereas the vendor mmc driver almost immediately returns
> here.
> 
> I wonder why this call to complete consumes so much time? Any ideas?

i don't know why, but how about putting the SDIO clk signal parallel to the
GPIOs at your osci? So could get a better view of the runtime behavior.

Btw you should also verify the necessary time between to 2 packets.

Stefan

> 
> [1] http://lxr.free-electrons.com/source/drivers/net/wireless/broadcom/
> brcm80211/brcmfmac/bcmsdh.c#L488
> 
> [2] http://lxr.free-electrons.com/source/drivers/mmc/host/mxs-mmc.c#L17
> 9
> 
> [3] http://lxr.free-electrons.com/source/drivers/mmc/core/core.c#L386
> 
> Best regards,
> Jörg Krause