All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frieder Schrempf <frieder.schrempf@kontron.de>
To: Tim Harvey <tharvey@gateworks.com>, Adam Ford <aford173@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: i.MX8MM Ethernet TX Bandwidth Fluctuations
Date: Mon, 10 May 2021 14:57:11 +0200	[thread overview]
Message-ID: <c18d0ed9-2f6e-1df2-e7aa-973e0aebfc45@kontron.de> (raw)
In-Reply-To: <CAJ+vNU2_VQRYzJKnHkLpJUYY7KZNGC8_fHj_7VcUdvHkbzFWGQ@mail.gmail.com>

Hi Tim,

On 07.05.21 17:34, Tim Harvey wrote:
> On Thu, May 6, 2021 at 12:20 PM Adam Ford <aford173@gmail.com> wrote:
>>
>> On Thu, May 6, 2021 at 9:51 AM Frieder Schrempf
>> <frieder.schrempf@kontron.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!
>>
>> I have seen a similar regression on linux-next on both Mini and Nano.
>> I thought I broke something, but it returned to normal after a reboot.
>>   However, with a 1Gb connection, I was running at ~450 Mbs which is
>> consistent with what you were seeing with a 100Mb link.
>>
>> adam
>>
> 
> Frieder,
> 
> I've noticed this as well on our designs with IMX8MN+DP83867 and
> IMX8MM+KSZ9897S. I also notice it with IMX8MN+DP83867. I have noticed
> it on all kernels I've tested and it appears to latch back and forth
> every few times I run a 10s iperf3 between 50% and 100% line speed.
> 
> I have no idea what it is but glad you are asking and hope someone
> knows how to fix it!

Thanks for providing that information. Yes, the latching effect between "slow" and normal speed now and then is exactly what I'm seeing, too. Good to know that this is something not only happening at my end!

Best regards
Frieder

WARNING: multiple messages have this Message-ID (diff)
From: Frieder Schrempf <frieder.schrempf@kontron.de>
To: Tim Harvey <tharvey@gateworks.com>, Adam Ford <aford173@gmail.com>
Cc: NXP Linux Team <linux-imx@nxp.com>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: i.MX8MM Ethernet TX Bandwidth Fluctuations
Date: Mon, 10 May 2021 14:57:11 +0200	[thread overview]
Message-ID: <c18d0ed9-2f6e-1df2-e7aa-973e0aebfc45@kontron.de> (raw)
In-Reply-To: <CAJ+vNU2_VQRYzJKnHkLpJUYY7KZNGC8_fHj_7VcUdvHkbzFWGQ@mail.gmail.com>

Hi Tim,

On 07.05.21 17:34, Tim Harvey wrote:
> On Thu, May 6, 2021 at 12:20 PM Adam Ford <aford173@gmail.com> wrote:
>>
>> On Thu, May 6, 2021 at 9:51 AM Frieder Schrempf
>> <frieder.schrempf@kontron.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!
>>
>> I have seen a similar regression on linux-next on both Mini and Nano.
>> I thought I broke something, but it returned to normal after a reboot.
>>   However, with a 1Gb connection, I was running at ~450 Mbs which is
>> consistent with what you were seeing with a 100Mb link.
>>
>> adam
>>
> 
> Frieder,
> 
> I've noticed this as well on our designs with IMX8MN+DP83867 and
> IMX8MM+KSZ9897S. I also notice it with IMX8MN+DP83867. I have noticed
> it on all kernels I've tested and it appears to latch back and forth
> every few times I run a 10s iperf3 between 50% and 100% line speed.
> 
> I have no idea what it is but glad you are asking and hope someone
> knows how to fix it!

Thanks for providing that information. Yes, the latching effect between "slow" and normal speed now and then is exactly what I'm seeing, too. Good to know that this is something not only happening at my end!

Best regards
Frieder

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-05-10 13:41 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-06 14:45 i.MX8MM Ethernet TX Bandwidth Fluctuations Frieder Schrempf
2021-05-06 14:45 ` Frieder Schrempf
2021-05-06 14:53 ` Dave Taht
2021-05-06 14:53   ` Dave Taht
2021-05-10 12:49   ` Frieder Schrempf
2021-05-10 12:49     ` Frieder Schrempf
2021-05-10 15:09     ` Dave Taht
2021-05-10 15:09       ` Dave Taht
2021-05-06 19:20 ` Adam Ford
2021-05-06 19:20   ` Adam Ford
2021-05-07 15:34   ` Tim Harvey
2021-05-07 15:34     ` Tim Harvey
2021-05-10 12:57     ` Frieder Schrempf [this message]
2021-05-10 12:57       ` Frieder Schrempf
2021-05-10 12:52   ` Frieder Schrempf
2021-05-10 12:52     ` Frieder Schrempf
2021-05-10 13:10     ` Adam Ford
2021-05-10 13:10       ` Adam Ford
2021-05-12 11:58 ` Joakim Zhang
2021-05-12 11:58   ` Joakim Zhang
2021-05-13 12:36   ` Joakim Zhang
2021-05-13 12:36     ` Joakim Zhang
2021-05-17  7:17     ` Frieder Schrempf
2021-05-17  7:17       ` Frieder Schrempf
2021-05-17 10:22       ` Joakim Zhang
2021-05-17 10:22         ` Joakim Zhang
2021-05-17 12:47         ` Dave Taht
2021-05-17 12:47           ` Dave Taht
2021-05-18 12:35           ` Joakim Zhang
2021-05-18 12:35             ` Joakim Zhang
2021-05-18 12:55             ` Frieder Schrempf
2021-05-18 12:55               ` Frieder Schrempf
2021-05-19  7:49               ` Joakim Zhang
2021-05-19  7:49                 ` Joakim Zhang
2021-05-19  8:10                 ` Frieder Schrempf
2021-05-19  8:10                   ` Frieder Schrempf
2021-05-19  8:40                   ` Joakim Zhang
2021-05-19  8:40                     ` Joakim Zhang
2021-05-19 10:12                     ` Frieder Schrempf
2021-05-19 10:12                       ` Frieder Schrempf
2021-05-19 10:47                       ` Joakim Zhang
2021-05-19 10:47                         ` Joakim Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c18d0ed9-2f6e-1df2-e7aa-973e0aebfc45@kontron.de \
    --to=frieder.schrempf@kontron.de \
    --cc=aford173@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-imx@nxp.com \
    --cc=netdev@vger.kernel.org \
    --cc=tharvey@gateworks.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.