• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 100 subscribers
  • Views 1438 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335X Poor Ethernet Performance after Linux 3.2

Tyson Thomas
Prodigy 70 points


Hi TI,

So I am currently facing a bit of an issue in regards to Linux in SDK 7.0 or 8 (even with the latest) doesn't really matter which one. I have been getting really poor performance or nothing at all depending on what phy-mode is in use. In the original board configuration file they appeared perform a phy-fixup in the old board configuration file. I can see now that the fix up has been moved to at803x.c in the /drivers/net/phy folder and a flag in the device tree determining if the fixup should occur. I can confirm that if the phy-mode is in rgmii-txid that the fixup operation occurs and does not report an error but I get an unusable ethernet. It detects the interface and no other odd behaviour occurs the ethernet is rendered useless.

When in RGMII-TXID it does not appear to transmit any data from the board but can receive data from other devices. Although I can only say this because other devices do not receive data from this but the data that is sent from other devices matches the amount of data sent to board.

Interesting side note though if in RGMII-TXID and connected to a cable that is limited to 100Mbit line it will work correctly although still with poor performance. (Approximately ~30Mbit/s transfer and ~80Mbit/s receiving).

When in RGMII it appears to work and is able to a DHCP lease and communicate with other devices correctly (great!) but this is at a cost of poor performance. Using iperf I see at  ~30Mbit/s transfer and ~90Mbit/s receiving. In Linux 3.2 the numbers are quite different, 280Mbit/s and 320Mbit/s or transfer and receive respectively.


I am using an Embest SBC8600b board which seems similar to a starter kit.

I have probably missed something really simple or changed something but it would be nice if TI could give me any leads in regards to this.

EDIT:
I should also point out that I am using AR8035 phys

  • 0
    TI__Guru**** 393215 points

    Hi,

    I will ask the Ethernet experts to look at this. The numbers you report do not match with what is reported in the Kernel performance wiki: http://processors.wiki.ti.com/index.php/Processor_SDK_Linux_Kernel_Performance_Guide#Ethernet_Driver

  • 0 in reply to Biser Gatchev-XID
    Prodigy 70 points
    Thank you, I believe with Linux 3.2 it is close to the numbers suggested in that wiki.
  • 0 in reply to Tyson Thomas
    TI__Genius 15510 points

    Actually, this could be a power management issue some folks see. Can you edit arch/arm/mach-omap2/cpuidle33xx.c and comment out these lines:

     70         {
     71                 .exit_latency = 176,
     72                 .target_residency = 300,
     73                 .power_usage = 562,
     74                 .flags = CPUIDLE_FLAG_TIME_VALID | AM33XX_FLAG_MPU_PLL,
     75                 .enter = am33xx_enter_idle,
     76                 .name = "C1",
     77                 .desc = "Bypass MPU PLL",
     78         },

    See if this helps.

    Steve K.

  • 0 in reply to Steve Kipisz
    TI__Genius 15510 points

    I was too quick posting. Leave those lines in but comment these out

    101         {
    102                 .exit_latency = 130,
    103                 .target_residency = 200,
    104                 .power_usage = 497,
    105                 .flags = CPUIDLE_FLAG_TIME_VALID | AM33XX_FLAG_MPU_PLL,
    106                 .enter = am33xx_enter_idle,
    107                 .name = "C1",
    108                 .desc = "Bypass MPU PLL",
    109         },

    Steve K.

  • 0 in reply to Steve Kipisz
    Guru 20755 points

    Hi,

    I also encounter degredation in ethernet performance when I use power mode features in kernel.

    I see that I get degregation when there is no activity in serial (from time of starting the test till finishing the test). I thought That it means that cpu gets into retention in such scenario, but to my surprise the retention counter did not change during the test:

    ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
    70254200

    ~ # ./iperf -c 150.42.40.220 -w 2000
    WARNING: TCP window size set to 2000 bytes. A small window size
    will give poor performance. See the Iperf documentation.
    ------------------------------------------------------------
    Client connecting to 150.42.40.220, TCP port 5001
    TCP window size: 3.91 KByte (WARNING: requested 1.95 KByte)
    ------------------------------------------------------------
    [ 5] local 150.42.40.221 port 49380 connected with 150.42.40.220 port 5001
    [ ID] Interval Transfer Bandwidth
    [ 5] 0.0-10.0 sec 7.67 MBytes 6.43 Mbits/sec

    ~ # cat /sys/devices/system/cpu/cpu0/cpuidle/state4/time
    70254200

    It seems to be related to power mode issues, but I don't understand why, and don't understand how to solve it.
    1. I would have expected that the retention counter will be incremented at the time of the test, but it is not, so how can it be explained ? Is it that there is some failure in the counter progress that can explain this ?
    2. When I set in code sleep_while_idle = 0.I have no degredation (though there is no entering into retention at all).

    Thanks for any feedback,

    Regards,
    Ran

  • 0
    Intellectual 480 points

    Hi Tyson,

    I'm seeing basically the same issue with the AR8035, were you able to resolve it?

    Please note that I had to use the txid/introduce the delay to have the proper offset.

    But other than that, everything else is what you had experienced.

    Thanks!