We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
Yes, and in my post (1st paragraph midway through) I mentioned that I used WireShark to monitor traffic, and that's how I found out about the retransmissions for each packet.
Lei
So you have heard of it. Do you know how to use it and to interpret what you see?
I think I do, but I'm not sure what you are getting at. What information do you think I should look for?
I can see that virtually every TCP packet experiences multiple retries
Im not sure, but this makes me think that maybe you are not populating the send buffer correctly or that you are not trying to send the TCP message at the correct state of the TCP machine.
You could be missinterpreting the effect of the invokation of the tcp_send, this function on his own does nothing but to populate a buffer to be send, the real work is done when the main_TcpNet is called and the state machine is on the right position.
Invoking tcp_send multiple times without allowing the state machine to do their job will send only the last population of the send buffer.
Make sure you are using the functions provided correctly.
Also the callback function gives you a clue of when the state machine is on the right position to send more messages, for example you could use the TCP_EVT_ACK to flag other part of you program that the buffer should be populated with the next segment of data.
Do not invoke tcp_send from inside the callback.
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
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