This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Tcp/IP Stack performance doubt

Hi, when I use MDK Network component(RL-TCPnet) based on RL-RTX, I find that the TCP/IP stack can only use polling mode other than interrupt mode? and it's interval is 20ms(I got it from 'eth_thread' in Event Viewer, it excutes every 20ms). Is that right?

The problem is how can I improve the performance within 1ms? If the Network comonent can not work out, is LWIP the better choice for real-time intended applications?

I'm looking forward for your reply. Thank you very much!

Parents
  • Wow,you’ve really been a big help. Thank you, Gordon. I still have some questions about the
    transmission time.

    1, If we use TCP tick of 10ms, does that mean ,when the application(our task)receives the data, 10ms have passed since the sender sends out the data, that is to say, it has 10ms delay from
    the sender to the receiver in the worst situation?

    2, "any protocol stack requires periodic calls for maintenance of sessions,All operations are carried out in a single task" , I think this task just need to call 'net_main ()' function ,for
    I find it from the document:

    The function net_main is the main function of the Network Core. It handles:
    Protocol time-outs
    ARP address cache
    Polling of the Ethernet controller for received data.

    And a lot MDK tcp examples just call net_main() in while(1) in main thread. But the 'eth_thread'
    I find from the Event Viewer excutes with 20ms interval accurately when no network cable
    connected. So do you know what the role 'eth_thread' plays? And this thread interval is the same
    thing with TCP tick ?

Reply
  • Wow,you’ve really been a big help. Thank you, Gordon. I still have some questions about the
    transmission time.

    1, If we use TCP tick of 10ms, does that mean ,when the application(our task)receives the data, 10ms have passed since the sender sends out the data, that is to say, it has 10ms delay from
    the sender to the receiver in the worst situation?

    2, "any protocol stack requires periodic calls for maintenance of sessions,All operations are carried out in a single task" , I think this task just need to call 'net_main ()' function ,for
    I find it from the document:

    The function net_main is the main function of the Network Core. It handles:
    Protocol time-outs
    ARP address cache
    Polling of the Ethernet controller for received data.

    And a lot MDK tcp examples just call net_main() in while(1) in main thread. But the 'eth_thread'
    I find from the Event Viewer excutes with 20ms interval accurately when no network cable
    connected. So do you know what the role 'eth_thread' plays? And this thread interval is the same
    thing with TCP tick ?

Children
  • I'm not familiar with that eth_thread. It's quite possible/likely that improvements have been made to TCPnet since I last had to read it.

    But I think you've basically answered your own question with Polling of the Ethernet controller for received data.

    That is certainly how I understood the operation before, so reception processing would be delayed by up to the calling period.

    It's really a shame that Keil don't allow easy access to the TCPnet source code so that people who have a need to understand it can.

  • The eth_thread actually waits for events from ethernet driver with a 20ms timeout.

    On frame receive event, the thread resumes instantly. A 20ms timeout is there to improve robustness.

    On timeout, eth_thread checks the driver again. This behavior improves robustness and stability of the system.

  • Yeah, got it, thank you!

    Just one more doubt, net_main() is the main function of the Network Core. It Polls of the Ethernet controller for received data, and I find the function is called frequently by main thread.

    But why it is designed to use polling mode? I think it is better to be designed like this: If there is no data received by the driver, the net_main() just waits for an event to occur; whenever the driver receives data, the driver should send an event to net_main() ,so it can be executed in time . Isn't it more effective? But I just cannot find how to do like this, for the TCPnet source code can't be accessed!

  • Actually it is the driver who defines the operation mode in Driver Capabilities. Network component is capable of using both, interrupt driven and polling mode of CMSIS ethernet driver.

    Here is an example of EMAC_LPC43xx.c ethernet driver capabilities:

    /* Driver Capabilities */
    static const ARM_ETH_MAC_CAPABILITIES DriverCapabilities = {
      0,                                /* checksum_offload_rx_ip4  */
      0,                                /* checksum_offload_rx_ip6  */
      0,                                /* checksum_offload_rx_udp  */
      0,                                /* checksum_offload_rx_tcp  */
      0,                                /* checksum_offload_rx_icmp */
      0,                                /* checksum_offload_tx_ip4  */
      0,                                /* checksum_offload_tx_ip6  */
      0,                                /* checksum_offload_tx_udp  */
      0,                                /* checksum_offload_tx_tcp  */
      0,                                /* checksum_offload_tx_icmp */
      (RTE_ENET_RMII) ?
      ARM_ETH_INTERFACE_RMII :
      ARM_ETH_INTERFACE_MII,            /* media_interface          */
      0,                                /* mac_address              */
      1,                                /* event_rx_frame           */
      1,                                /* event_tx_frame           */
      1,                                /* event_wakeup             */
      (EMAC_TIME_STAMP) ? 1 : 0         /* precision_timer          */
    };
    

    The method you are suggesting is already implemented in new Network Dual Stack. The system creates also a Network Core thread in netInitialize function. This thread waits for an event to occur. An event is either a frame received from any interface or a timer tick. Then net_main is processed, protocol timers are updated and Network Core thread waits for another event to come.

  • Franc,

    Is that new Network Dual Stack now available? Last time I looked, it was in beta.

    We've got a new project coming up and I'd like to find out as much as possible about the suitability of it.

  • Thank you , Franc and Gordon. I would choose new Network Dual Stack to ensure real-time.

    By the way, Franc , I think there will be more RTX and Network users if there is a list of the Network performance analysis .

    For example , what's the maximum pixel(YUV420) can be transmitted stablely over the Network with specified CPU frequency (a lot of people use cortex-M MCU to deal with video processing ), and what's the latency time . Though users can calculate it by themselves, they just want to have a visualized graph or something like that, to increase their confidence in using it.