netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hector Palacios <hector.palacios@digi.com>
To: Marek Vasut <marex@denx.de>
Cc: "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"fabio.estevam@freescale.com" <fabio.estevam@freescale.com>
Subject: Re: FEC performance degradation on iMX28 with forced link media
Date: Mon, 25 Nov 2013 09:56:04 +0100	[thread overview]
Message-ID: <529310A4.70906@digi.com> (raw)
In-Reply-To: <201311240540.23813.marex@denx.de>

On 11/24/2013 05:40 AM, Marek Vasut wrote:
> Hi Hector,
>
>> Hello,
>>
>> When forcing the Ethernet PHY link media with ethtool/mii-tool on the
>> i.MX28 I've seen important performance degradation as the packet size
>> increases.
>>
>> On the target:
>> # mii-tool eth0 -F 10baseT-FD
>> # netpipe
>>
>> On the host:
>> # netpipe -h <target-ip> -n 1
>> ...
>> 44:    1024 bytes      1 times -->      6.56 Mbps in    1191.00 usec
>> 45:    1027 bytes      1 times -->      6.56 Mbps in    1193.52 usec
>> 46:    1533 bytes      1 times -->      0.60 Mbps in   19600.54 usec
>> 47:    1536 bytes      1 times -->      0.46 Mbps in   25262.52 usec
>> 48:    1539 bytes      1 times -->      0.57 Mbps in   20745.54 usec
>> 49:    2045 bytes      1 times -->      0.74 Mbps in   20971.95 usec
>> ...
>> On loop 46, as the packet size exceeds the MTU (1500) performance falls
>> from 6.56Mbps to 0.60Mbps.
>>
>> Going back to 100baseTX-FD, but still forced (autonegotiation off), the
>> same occurs: On the target:
>> # mii-tool eth0 -F 100baseTx-FD
>> # netpipe
>>
>> On the host:
>> # netpipe -h <target-ip> -n 1
>> ...
>> 58:    6141 bytes      1 times -->     39.74 Mbps in    1179.03 usec
>> 59:    6144 bytes      1 times -->     41.83 Mbps in    1120.51 usec
>> 60:    6147 bytes      1 times -->     41.39 Mbps in    1133.03 usec
>> 61:    8189 bytes      1 times -->      6.36 Mbps in    9823.94 usec
>> 62:    8192 bytes      1 times -->      6.56 Mbps in    9521.46 usec
>> 63:    8195 bytes      1 times -->      6.56 Mbps in    9532.99 usec
>> ...
>> only this time it happens with a larger packet size (8189 bytes).
>>
>> With autonegotiation on, performance is ok and does not suffer these drops.
>>
>> I've reproduced this on the mx28evk board but it also happens in my
>> hardware, with different PHY on v3.10.
>> I also tried on an old v2.6.35 kernel and the issue was reproducible as
>> well, though it happened with larger packet sizes than it happens with
>> v3.10:
>> ...
>> 75:   32771 bytes      1 times -->     49.64 Mbps in    5036.50 usec
>> 76:   49149 bytes      1 times -->     46.18 Mbps in    8120.48 usec
>> 77:   49152 bytes      1 times -->     43.30 Mbps in    8660.46 usec
>> 78:   49155 bytes      1 times -->     40.10 Mbps in    9351.46 usec
>> 79:   65533 bytes      1 times -->      2.03 Mbps in  246061.04 usec
>> 80:   65536 bytes      1 times -->      2.21 Mbps in  226516.50 usec
>> 81:   65539 bytes      1 times -->      1.45 Mbps in  344196.46 usec
>> ...
>>
>> Could there be any issue with packet fragmentation?
>> I tried the same on imx6sabresd but here the issue is not reproducible. I
>> don't know if the higher CPU frequency might be hiding the problem,
>> though.
>>
>> Any idea about what can make the difference between forcing media vs
>> autonegotiation?
>
> Let me ask, this might be unrelated, but I will still go ahead. Do you also
> observe packetloss? You can check with iperf:
>
> On host machine (PC): iperf -u -s -l 4M -i 60
> On target: iperf -u -c <hostip> -t 3600 -B 100M -i 60

Yes, with forced 100baseTX-FD there is a small packet loss:

[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-60.0 sec   339 MBytes  47.4 Mbits/sec   0.075 ms   61/242070 (0.025%)
[  3] 60.0-120.0 sec   339 MBytes  47.4 Mbits/sec   0.209 ms   45/242122 (0.019%)
[  3] 120.0-180.0 sec   339 MBytes  47.5 Mbits/sec   0.084 ms   70/242237 (0.029%)
[  3] 180.0-240.0 sec   339 MBytes  47.4 Mbits/sec   0.030 ms   80/241993 (0.033%)
[  3] 240.0-300.0 sec   340 MBytes  47.5 Mbits/sec   0.042 ms  111/242363 (0.046%)
[  3] 300.0-360.0 sec   339 MBytes  47.4 Mbits/sec   0.038 ms   93/241972 (0.038%)
[  3] 360.0-420.0 sec   339 MBytes  47.5 Mbits/sec   0.030 ms   78/242214 (0.032%)
[  3] 420.0-480.0 sec   339 MBytes  47.4 Mbits/sec   0.090 ms   77/241980 (0.032%)
[  3] 480.0-540.0 sec   339 MBytes  47.4 Mbits/sec   0.025 ms  125/242058 (0.052%)

With autonegotiated 100baseTX-FD, there is not:

[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-60.0 sec   336 MBytes  47.0 Mbits/sec   0.038 ms    0/239673 (0%)
[  3] 60.0-120.0 sec   337 MBytes  47.1 Mbits/sec   0.078 ms    0/240353 (0%)
[  3] 120.0-180.0 sec   337 MBytes  47.1 Mbits/sec   0.047 ms    0/240054 (0%)
[  3] 180.0-240.0 sec   337 MBytes  47.1 Mbits/sec   0.038 ms    0/240195 (0%)
[  3] 240.0-300.0 sec   337 MBytes  47.1 Mbits/sec   0.038 ms    0/240109 (0%)
[  3] 300.0-360.0 sec   337 MBytes  47.1 Mbits/sec   0.035 ms    0/240101 (0%)
[  3] 360.0-420.0 sec   337 MBytes  47.0 Mbits/sec   0.031 ms    0/240032 (0%)
[  3] 420.0-480.0 sec   336 MBytes  47.0 Mbits/sec   0.036 ms    0/239912 (0%)


Best regards,
--
Hector Palacios

  reply	other threads:[~2013-11-25  9:03 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-22 12:40 FEC performance degradation on iMX28 with forced link media Hector Palacios
2013-11-24  4:40 ` Marek Vasut
2013-11-25  8:56   ` Hector Palacios [this message]
2013-12-18 16:43     ` FEC performance degradation with certain packet sizes Hector Palacios
2013-12-18 17:38       ` Eric Dumazet
2013-12-19  2:44         ` fugang.duan
2013-12-19 23:04           ` Eric Dumazet
2013-12-20  0:18             ` Shawn Guo
2013-12-20  3:35       ` fugang.duan
2013-12-20 15:01         ` Hector Palacios
2013-12-23  1:08           ` fugang.duan
2013-12-23  2:52           ` fugang.duan
2014-01-21 17:49             ` Marek Vasut

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=529310A4.70906@digi.com \
    --to=hector.palacios@digi.com \
    --cc=fabio.estevam@freescale.com \
    --cc=marex@denx.de \
    --cc=netdev@vger.kernel.org \
    /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 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).