• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1255 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.

RTOS/TMS320C6678: C6678 DSP network bandwidth test

Andranik Aslanyan
Intellectual 445 points

Part Number: TMS320C6678

Tool/software: TI-RTOS

Hello,

We do development on C6678 DSP and for network testing we've modified the PA_emacExample_evmc6678_C66BiosExampleProject a little bit and loaded the application to DSP in no_boot mode.

Especially to test the network bandwidth we just increased the MAX_NUMB_PACKETS count from 10u to 1000000u to have enough time to measure the actual bandwidth, disabled the autonegotation and changed the mode from CPSW_LOOPBACK_INTERNAL to CPSW_LOOPBACK_EXTERNAL


Currently on the other end we receive only 120Mbps instead of 1000Mbps (or something closer to it)

Could you help please discover the root cause of low transmit bandwidth suggest another precise methot to measure the network bandwidth on DSP network ports?

Regards

Andranik Aslanyan

  • 0
    Mastermind 6670 points
    Hi,

    To perform such a test I suppose you also modify the example to increase the number of TX descriptor and retry a packet in case of TX descriptor dry out.

    Try to look at the receiver performance. For instance, with a C6678 custom network driver and iperf transmitter, in my environment I can see that the number of packet lost on the Win7 PC side depend (also) on the size of the receiver socket buffer size.

    Increasing the receiver buffer size from the default 8K (Win7) to 64K, the number of packet lost decrease from 50% to 0.1%. Even in this case I have to slow down a bit the transmitter (the C6678).
  • 0 in reply to Alberto Chessa
    Intellectual 445 points
    Hello Alberto,

    We've succeeded to test the C6678 transmit bandwidth and it's pretty good - till the 930Mbps.
    The last goal is to test the receive bandwidth - we see on the host side again 900+Mbps but can't measure the receive bandwidth on C6678 side.
    Is there any example either on Processor SDK or MCSDK side for this purpose? And if no - could you please suggest a method for doing that?

    P.S.
    Currently I'm sending the packets to C6678 from Linux PC via the IPERF tool with the following command:

    iperf -c 192.168.1.1 -l 32k -i 1 -u -b 1000M


    Regards
    Andranik
  • 0 in reply to Andranik Aslanyan
    Intellectual 445 points

    Alberto,

    Did you have a chance to take a look into this?

    Andranik

  • 0 in reply to Andranik Aslanyan
    Mastermind 6670 points
    Hi,
    How do you archive 930Mbos on host side? Increased received buffer size?

    About the Rx, I'm not aware about a ready to use tool on the C6678 side. Maybe there is something in the TI NDK.

    I also use iperf, but since I don't use TI NDK, I implements a basic iperf rx server (but I cannot share the code, sorry).
  • 0 in reply to Alberto Chessa
    Intellectual 445 points
    I've increased the pktMatch[] array content's payload in
    ~/ti/pdk_c667x_2_0_7/packages/ti/drv/pa/example/emacExample/src/c66x/bios/framework.c file from 80 bytes to 800 to achieve 930 Mbps .

    Could you please at least describe the basic steps to do in DSP and host sides to run such iperf rx server?

    Andrranik
  • 0 in reply to Andranik Aslanyan
    Mastermind 6670 points
    Hi,
    Since the basic example has not UDP sockets support, I think you have to modify the Rx VerifyPacket() to capture the iperf messages (UDP only).

    You have to interpret the received packet to find the UDP header and the payload

    The destination IP port at byte 0x24 should be 5001 (0x89, 0x13 in network big endian order), while iperf payload should begin at offset 0x2A.

    The first 32 bits payload word is the iperf packet ID (a signed number, in network order)

    So, if destination port = 5001:
    1. id=0 ? iperf start, save the C6678 time stamp t_start=TSCL. total_received=packet_size
    2. id > 0 : packet number sequence (you can verify if you loose packet), total_received+=packet_size
    3. id = -previous_id, last packet (negative), t_stop=TSCL. total_received+=packet_size

    t_elapsed = t_stop - t_start (nanoseconds @1GHz)

    Probably you have to manually add the C6678 MAC/IP pair to your PC ARP table, since the example is not able to reply to ARP request. In my SDK version, the default C6678 IP is 192.168.2.100, so you have to use that number in the IPERF command.

    Note that to close the test on the PC side, you have to send back the last packet (the one with a negative id), but replacing the destinations with the sources (MAC address, IP address, IP port) and calculate the IP checksum.

    I'm not sure about the offsets in the ethernet packet (I use an UDP layer, not raw access to the packets), but you can verify them with a network monitor like WireShark.