Message-ID: <c9f26a11-bb53-e3aa-606c-a592365a9a1e@kontron.de>
Date:   Mon, 10 May 2021 14:49:23 +0200
From:   Frieder Schrempf <frieder.schrempf@...tron.de>
To:     Dave Taht <dave.taht@...il.com>
Cc:     NXP Linux Team <linux-imx@....com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: i.MX8MM Ethernet TX Bandwidth Fluctuations

Hi Dave,

thanks for the input. I really don't know much about the networking stack, so at the moment I can only provide the values requested below, without knowing what it really means.

What's so strange is, that the performance is actually good in general and only "snaps" to the "bad" state and back after some time or after repeated test runs.

And by the way, the ethernet driver in use is the FEC driver at drivers/net/ethernet/freescale/fec_main.c.

On 06.05.21 16:53, Dave Taht wrote:
> I am a big fan of bql - is that implemented on this driver?
> 
> cd /sys/class/net/your_device_name/queues/tx-0/byte_queue_limits/
> cat limit

~# cat /sys/class/net/eth0/queues/tx-0/byte_queue_limits/limit
0

> 
> see also bqlmon from github
> 
> is fq_codel running on the ethernet interface? the iperf bidir test
> does much better with that in place rather than a fifo. tc -s qdisc
> show dev your_device

~# tc -s qdisc show dev eth0
RTNETLINK answers: Operation not supported
Dump terminated

Best regards
Frieder

> 
> Also I tend to run tests using the flent tool, which will yield more
> data. Install netperf and irtt on the target, flent, netperf, irtt on
> the test driver box...
> 
> flent -H the-target-ip -x --socket-stats -t whateveryouaretesting rrul
> # the meanest bidir test there
> 
> flent-gui *.gz
> 
> On Thu, May 6, 2021 at 7:47 AM Frieder Schrempf
> <frieder.schrempf@...tron.de> wrote:
>>
>> Hi,
>>
>> we observed some weird phenomenon with the Ethernet on our i.MX8M-Mini boards. It happens quite often that the measured bandwidth in TX direction drops from its expected/nominal value to something like 50% (for 100M) or ~67% (for 1G) connections.
>>
>> So far we reproduced this with two different hardware designs using two different PHYs (RGMII VSC8531 and RMII KSZ8081), two different kernel versions (v5.4 and v5.10) and link speeds of 100M and 1G.
>>
>> To measure the throughput we simply run iperf3 on the target (with a short p2p connection to the host PC) like this:
>>
>>         iperf3 -c 192.168.1.10 --bidir
>>
>> But even something more simple like this can be used to get the info (with 'nc -l -p 1122 > /dev/null' running on the host):
>>
>>         dd if=/dev/zero bs=10M count=1 | nc 192.168.1.10 1122
>>
>> The results fluctuate between each test run and are sometimes 'good' (e.g. ~90 MBit/s for 100M link) and sometimes 'bad' (e.g. ~45 MBit/s for 100M link).
>> There is nothing else running on the system in parallel. Some more info is also available in this post: [1].
>>
>> If there's anyone around who has an idea on what might be the reason for this, please let me know!
>> Or maybe someone would be willing to do a quick test on his own hardware. That would also be highly appreciated!
>>
>> Thanks and best regards
>> Frieder
>>
>> [1]: https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcommunity.nxp.com%2Ft5%2Fi-MX-Processors%2Fi-MX8MM-Ethernet-TX-Bandwidth-Fluctuations%2Fm-p%2F1242467%23M170563&amp;data=04%7C01%7Cfrieder.schrempf%40kontron.de%7C157b00b2686447fd9a7108d9109ecbc6%7C8c9d3c973fd941c8a2b1646f3942daf1%7C0%7C0%7C637559096478620665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=SFT%2Boic9C1sirw%2BT1o1qRNNUe4H9bk2FHkLQpdy489I%3D&amp;reserved=0
> 
> 
> 

Powered by blists - more mailing lists