• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 2661 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.

TM4C1294KCPDT: Throughput Test in TM4C1294 Micro-Controller

John Chen65
Prodigy 250 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: EK-TM4C129EXL

Hello

I'm trying to test throughput of Ethernet in TM4C1294 of micro-controller.

Did you verify successfully?

Thanks,

John Chen

  • 0
    Guru 117855 points

    Does, "Throughput of Ethernet" adequately describe/define/detail the "depth of such test?"
    Might: "Speed, Duration, Robustness" (via BER) [Bit Error Rate] enter into such "throughput" - at least to (some) degree?

    And - how does one define, "success" of such test?      Devil (always) in such detail - none having (yet) arrived this space...

  • 0
    TI__Guru**** 191886 points
    Hi John,
    No, we do not have any Ethernet benchmark. I did some search of the forum and there was post sharing that they were able to reach 70Mb/s in a constant UDP connection. I think a lot is depending on the CPU loads too.
  • 0 in reply to Charles Tsai
    Prodigy 250 points

    Hi Charles,

    I'm a hardware engineer, in our design phase we will confirm performance, signal quality and bit error rate. Make sure PCB layout quality.

    If you doesn't have such as benchmark, how do you estimate layout design? Only measure signal?

    We are worry the noise coupling will create by overall system running on heavy load, that's why verify benchmark of bit error rate.

    Thanks,

    John

  • 0 in reply to Charles Tsai
    Guru 92251 points

    Charles Tsai said:
    I did some search of the forum and there was post sharing that they were able to reach 70Mb/s in a constant UDP connection. I think a lot is depending on the CPU loads too.

    I was trying the tcpEcho example from tirtos_tivac_2_16_01_14 to see what throughput could easily achieve.

    The default TI-RTOS network settings for the tcpEcho example are to keep the memory footprint relatively small. The sizes were adjusted to try and send/receive 5840 bytes for each socket call, which is 4 Ethernet frames with the maximum TCP payload of 1460 bytes.

    The supplied tirtos_tivac_2_16_01_14/packages/examples/tools/tcpSendReceive was run on a Linux host PC to generate the test traffic to the tcpEcho example running on a EK-TM4C129EXL. As the tcpWorker task in the tcpEcho example and the tcpSendReceive host program only call either recv() or send() at once multiple instances of tcpSendReceive were run on the Linux host PC. When four instances of tcpSendReceive were run each with the following command line arguments the Ethernet throughput in each direction was 55.5 megabits/second:

    ~/ti/tirtos_tivac_2_16_01_14/packages/examples/tools/tcpSendReceive 192.168.0.4 1000 1 -s0 -l5840

    The rationale for running four instances of the tcpSendReceive host program was to try and get a target send(), a target recv(), a host send() and a host recv() function being called together to try and maximise packet throughput.

    With further investigation / tuning it may be possible to increase the throughput. Would need to determine if the bottleneck is in the TI-RTOS NDK software stack.

    The modified tcpEcho example is attached, which also includes the fixed EMACSnow.c to fix the problem described in TivaC NDK TCP: Can't receive large packets (>=1460 bytes) where the maximum sized Ethernet frame couldn't be received by the TI-RTOS NDK.

    tcpEcho_EK_TM4C1294XL_TI_TivaTM4C1294NCPDT.zip

  • 0 in reply to Chester Gillon
    Guru 117855 points

    Excellent - well done - and "inspired."     One qualm - the bottleneck (may) have multiple participants - and may (dynamically) shift - depending upon multiple factors.

    Seizing upon (just one) may lessen the detection (and impact) of  "other suspects."

    Might a "more standard" - general "benchmark protocol" - exist?       And - if so - deployed/tested...      (such really  "falls at the feet"  of the o.p.)

  • 0 in reply to cb1_mobile
    Guru 92251 points

    cb1_mobile said:
    Seizing upon (just) one may lessen the detection (and impact) of  "other suspects."

    Agreed.

    cb1_mobile said:
    I question whether a "more standard" - general "benchmark protocol" - exists.       And - if so - may be deployed...

    In the past have used the "blaster/blastee" is ethernet performance test tool, which is able to be compiled for Linux / Unix, Windows or VxWorks operating systems. With Linux running on am ARM Cortex-A15 based system communicating with a Linux PC over a 100Mbit Ethernet link was able to achieve 11730806 bytes/sec over a TCP socket, which is 93.8 Mbits/second of TCP data, which will be a higher rate on the physical link due to Ethernet / IP / TCP headers.

    I haven't yet attempted to convert blaster/blastee to run on a Tiva device but might allow a higher Ethernet link utilisation.

    From a quick look at the TI Network Developer's Kit (NDK) v2.25 API Reference Guide there is also the option of TCP sockets that use the SOCK_STREAMNC stream type which eliminates one or two receive data copies (depending on which recv() socket function is used). When sending large bursts of data, to generate maximum Ethernet link bandwidth, may help to increase the throughput.

    Edit: correction to link to the correct API Reference Guide

  • 0 in reply to Chester Gillon
    TI__Guru**** 191886 points
    Hi Chester,
    Hi Chester,
    Thank you very much for sharing your findings.
  • 0 in reply to Charles Tsai
    Guru 117855 points

    Indeed - great job - thank you Chester - much appreciated.        Pity that the vendor cannot detail "summer interns" to run, document, compare/contrast - and then publish such results...

    (it is realized that "lesser tasks" require less planning - yet there appears both a "client-user need" and "benefits to the vendor AND intern(s)" - should this "fitting intern utilization" be adopted...)