Hi all,
I have some questions and I would be grateful if you could help me. As you know, by adding a Network library, the library without open source needs good documentations. The documentation @ Keil and ARM websites is appropriate for many uses but for networks needs to be completed.
My questions:
1) In the Net_Config_ETH_0.h file, what is the OS Resource Settings?
2)In Net_Config.c, what is the OS Resource Settings? What does define its size
To change the default OS resource settings for the Network Core, use Core Thread Stack Size. The default value is 1024 bytes
3) In Net_Config.c, what is the Memory Pool Size?
The Memory Pool Size specifies the amount of RAM in bytes allocated for the memory pool. The buffers for the network packets are allocated from this memory pool. Usually, the default value of 12000 bytes is sufficient.
Does it get this memory from RTOS Global Dynamic memory?
4) How can I define the maximum data size and packet numbers per second if I use TCP or UDP protocol? I am using STM32F10x series with 72 MHz and a Phi with 50 MHz resource clock with RMII protocol.
5) How much time does a packet need to be transmitted after using netUDP_Send or netTCP_Send?
6) Is there any limitation for the Network on tick number or Kernel frequency of RTOS?
7) If I send the 30Bytes UDP packet each 100us, how the network library handle it? It sends them very fast or accumulate them in in queue form?
Thank you.
The tick frequency of the RTOS kernel of 1000 Hz was chosen for good reason. Changing it makes no sense, but results in the RTX kernel spending much more time on kernel management, leaving less CPU time for the user application.
The correct design would be cooperative multitasking. This means that in the interrupt, for example, an event flag or a message is sent to a thread that is waiting for it. The RTX then immediately switches to this thread, regardless of how high the tick frequency of the kernel is. And please stop using round-robin scheduling in your application.
The network kernel generally needs 100ms ticks for correct recovery times. So if e.g. the retransmit timeout should be 2 seconds, then in your case it is only 200ms. This will probably cause some retransmissions to fail and the network stack to behave unstable.
Dear Franc,
I am thankful for your help and sorry for the delay in my response because I was implementing your suggestions during these weeks.
It works fine, with the default RTOS values and I managed the interrupts with your recommendations.
Thank you again for your help.
Dear Frunc,
Sorry again, I take your time.
In Net_Config_TCP.h, I am faced with two options and I would be grateful if you could explain them.
// <o>Number of Retries <0-20> // <i>How many times TCP module will try to retransmit data // <i>before giving up. Increase this value for high-latency // <i>and low throughput networks. // <i>Default: 5 #define TCP_MAX_RETRY 5 // <o>Retry Timeout in seconds <1-10> // <i>If data frame not acknowledged within this time frame, // <i>TCP module will try to resend the data again. // <i>Default: 4 #define TCP_RETRY_TOUT 4 // <o>Default Connect Timeout in seconds <1-65535> // <i>If no TCP data frame has been exchanged during this time, // <i>the TCP connection is either closed or a keep-alive frame // <i>is sent to verify that the connection still exists. // <i>Default: 120 #define TCP_DEFAULT_TOUT 15
It means if each packet is not acknowledged within TCP_RETRY_TOUT time (for example 4 seconds), it will retransmit the data up to TCP_MAX_RETRY(for example 5) times.
1)This means that each packet will be stored in the memory buffer (NET_MEM_POOL_SIZE, for example, 12000 bytes) defined in the Net_Config file until it is acknowledged or the system starts sending packets after the elapsed time of TCP_RETRY_TOUT * TCP_MAX_RETRY. Am I correct?
If we send a 1 kilobyte (1KB) packet every 100 milliseconds (ms), the buffer will store the memory for all of them until they are acknowledged. For the worst-case scenario, TCP_RETRY_TOUT * TCP_MAX_RETRY * 1KB * 10 = 200,000 bytes, which is more than the NET_MEM_POOL_SIZE of 12,000 bytes.
2)If I set the TCP_MAX_RETRY to zero, the sender will save the buffer for TCP_RETRY_TOUT(because it can not be set to zero) and wait for each packet to be acknowledged and after TCP_RETRY_TOUT the memory will be released. This means that after each transmission, it will release the buffer after the TCP_RETRY_TOUT timeout. While we may experience some packet loss during transmission, we will not encounter memory loss. Is there any problem if I set the TCP_MAX_RETRY to zero? Does it disconnect my connection before TCP_DEFAULT_TOUT?
In addition, the "netTCP_Send" function and regarding the documentations, "The buffer will be released, no matter if netTCP_Send is successful or not." , it will save memory at least for TCP_RETRY_TOUT seconds. Am I right?
1. Yes, that is correct. Each packet is stored in the memory pool until it is acknowledged by the other side.
2. The values are actually initial values. TCP sockets implement optimization algorithms that optimize the transmission, such as: slow start, congestion avoidance, fast retransmission, sliding window and others. One of these algorithms is to measure RTT time and reduce retransmission timeouts, which can be as low as 100 ms in low latency networks. I suggest leaving the maximum number of retransmission retries at a default value.
3. Yes you are right about that.
I appreciate your explanations and help. Thank you for your comment.