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: Ethernet transmit delay

Part Number: TMS320C6678


Tool/software: TI-RTOS

Hi,

I am working on a project that is based on the PA_emacExample project in the pdk_c667x_2_0_9 examples, and I have a problem with the transmitting process

I am transmitting 32 packets of size 1486 bytes and I find out that while transmitting the second and the 17th packets there is a delay of 200 us(i can see it in wireshark) all the other packets transmit time is 0-1 us.

I need to remove this delay, because i am waiting for a confirmation message from the host side and all 32 packets need to be delivered ASAP.

any ideas ? suggestions ? 

Jameel

  • Hi,

    I guess this is a custom board. Do you have a JTAG connector mounted on it? Can you connect to your board step into the code and try to find out where this delay is being added (at which function)?

    Best Regards,
    Yordan
  • Hi Yordan,

    thanks for the reply, actually I am using the evaluation module, debugging the code does not help much, the problem is happening in the background and I'm not sure where to look for it, I only push the packets using the SendPacket() method from the example project in a while loop 32 times, and it just pushes the packets (Qmss_queuepush()) and the delay happens when the driver sends the packets.

    Best Regards,

    Jameel

  • Jameel,

    Do you notice the same behavior using the unmodified PA_emacExample project? What are the modifications you've made?

    Best Regards,
    Yordan
  • Hi,

    Searching int32_t SendPacket (int emac_dest_port), at the end there is a:

    /* Increment the application transmit counter */
    gTxCounter ++;

    /* Give some time for the PA to process the packet */
    CycleDelay (10000);

    Remove this CycleDelay (10000); or reduce this CycleDelay (10000); You should be able to see much smaller inter packet gap in Wireshark.

    Regards, Eric
  • Hi Eric and Yordan,
    Eric i actually tried that but the process of sending the packets seems to be not related to this delay, it will only delay the application but the packets will be sent exactly the same.
    Yordan, I checked the original PA_emac Project, looks like it has a delay only after sending 32 packets (number of descriptors?) every 32 packets the first one has a delay of ~300-600us , but my code has smaller delay almost every 16 packets.

    Regards, Jameel
  • Jameel,

    I tried the pdk_c667x_2_0_13\packages\MyExampleProjects\PA_emacExample_evmc6678_C66BiosExampleProject. Attached is the Wireshark capture with 100 packets, I don't see IPG ~300-600us.

    https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/PA_5F00_100.pcapng

    "because i am waiting for a confirmation message from the host side and all 32 packets need to be delivered ASAP." In your real application, there may be interrupt or DSP is busy processing other tasks, you can't guarantee that the packets are sent out in strict time interval.  I thought you may need to relax the timeout on the receiver side.

    Regards, Eric

  • Hey Eric,
    This does not help much due to the time intervals that you currently have between packets, if you check the time spent until you hit packet 32 you will find it takes about 800 us, which is exactly what i want to lower, currently my application is at ~400 us and i need it to be lower if possible.
  • Hi,

    If I understood you correctly, you want to transmit 32 packets each with 1.5KB in size for a total time less than 400 us: 32*1500*8/(400*10^(-6)) = 960 Mbps. This is not likely to improve further, because:
    1) the SGMII speed is 1000 Mbps, the performance depends on the driver optimization. The PA EMAC example is designed as a packet loop back example to show how to do CPPI, QMSS, PA setup, configure the TX, RX queue, ... it is not for performance test.
    2) The NDK NIMU is the example for network throughput. Some customer developed the TCP or UDP application on top of it, and throughput is typically 600-700 Mbps, some get 920 Mbps. I don't see any performance around 960-1024Mbps.

    "currently my application is at ~400 us and i need it to be lower if possible."====> If you already achieved ~400us for this, this is already the best.

    Regards, Eric