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
next prev parent 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).