Tcp/IP Stack performance doubt

I've not updated to 5.14, but it's possible they've simply changed the name of the define (that is something they've had a habit of doing in the past). It specifies the number of OS ticks between TCP stack processing maintenance.

So, you need to update this and the frequency of the OS ticks.

Regarding interrupt versus polling mode, the Ethernet driver uses interrupts, but the TCP protocol stack does not. It doesn't really make sense, except to note that any protocol stack requires periodic calls for maintenance of sessions. All operations are carried out in a single task.

Of course, increasing the frequency of these periodic checks will increase the total proportion of time spent in the protocol stack, but doing this does provide a far more responsive stack. It's a classic compromise situation.

As an example, we use an OS tick of 1ms and a TCP tick of 10ms, running on a CPU operating at just over 200MHz. For our requirements, it works very well.

I've not updated to 5.14, but it's possible they've simply changed the name of the define (that is something they've had a habit of doing in the past). It specifies the number of OS ticks between TCP stack processing maintenance.

So, you need to update this and the frequency of the OS ticks.

Regarding interrupt versus polling mode, the Ethernet driver uses interrupts, but the TCP protocol stack does not. It doesn't really make sense, except to note that any protocol stack requires periodic calls for maintenance of sessions. All operations are carried out in a single task.

Of course, increasing the frequency of these periodic checks will increase the total proportion of time spent in the protocol stack, but doing this does provide a far more responsive stack. It's a classic compromise situation.

As an example, we use an OS tick of 1ms and a TCP tick of 10ms, running on a CPU operating at just over 200MHz. For our requirements, it works very well.

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 ?

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.

It is in beta 2 now.

http://www.keil.com/pack/doc/mw/Network_DS/html/index.html

Many thanks.

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.