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 packets experience lots of retries

Hello all,

I'm using the RL TCP/IP stack in a standalone manner (without a RTOS) on an ARM 9 chip (Atmel's SAM9g20). The PHY transceiver I use is an Micrel KSZ8031RNL chip which is configured for auto speed negotiation. I'm using MDK-ARM professional 4.54 for development. When I transmit/receive a signal TCP/IP packet, everything works fine. However, if the data packet spans multiple TCP packets (with the maximum size of 1460), the transmission to my board appears to be very slow. In WireShark, I can see that virtually every TCP packet experiences multiple retries. This problem is one-directional, going from a PC program to my board. When a large amount of data is requested from my board, the transmission of packets seems fast with no retries at all.

I tested this with a couple of PC software, one written in C# using Microsoft .net framework and another written in Java using whatever TCP/IP stack Java has available, and they both experience the same symptom. So it seems that the problem is on my end.

In my net_config, I only have UDP sockets and TCP sockets enabled (with DHCP enabled). The application is just a straightfoward TCP client. I'm green on ethernet communication, so I don't even know where to start looking for a solution. Can anyone kindly suggest anything that I should try?

Thanks.

Lei Zong

Parents
  • Hi Christian, thank you for the helpful suggestion.

    I should mention that although that every incoming packet experiences multiple retries, all of them are received correctly, it's just the speed is very slow for a large message that spans multiple TCP/IP packets. No retries at all if a small message that can fit within 1 TCP/IP packet is transmitted or received. No retries either for a large outgoing message (from my embedded board point of view) that spans multiple TCP packets.

    So given that my problem is one directional (receiving rather than sending), I don't think it's the send buffer. It could be the receive buffer, but I'm at a lost what could be wrong. When data arrives, I get a TCP_EVT_DATA event in my callback function where I save the data. I call timer_poll() in an interrupt service routine that occurs every 50ms. Main_TcpNet() is called in a main while loop, which should run way faster than 50ms/cycle.

    Thanks. Lei

Reply
  • Hi Christian, thank you for the helpful suggestion.

    I should mention that although that every incoming packet experiences multiple retries, all of them are received correctly, it's just the speed is very slow for a large message that spans multiple TCP/IP packets. No retries at all if a small message that can fit within 1 TCP/IP packet is transmitted or received. No retries either for a large outgoing message (from my embedded board point of view) that spans multiple TCP packets.

    So given that my problem is one directional (receiving rather than sending), I don't think it's the send buffer. It could be the receive buffer, but I'm at a lost what could be wrong. When data arrives, I get a TCP_EVT_DATA event in my callback function where I save the data. I call timer_poll() in an interrupt service routine that occurs every 50ms. Main_TcpNet() is called in a main while loop, which should run way faster than 50ms/cycle.

    Thanks. Lei

Children
  • Hi Lei,

    Sorry for the late reply,

    when I send data from PC application to microP using TCP I take control of the size of the data buffers I send, I make the population of the individual TCP packets myself to adjust to maximum size of individual TCP.

    I dont let PC application to subdivide my buffers, I mean I dont pass a too large buffer that overflows a single max packet so my PC TCP stack dont subdivide it, I hope this helps you.

    Best regards