TCP/IP stack on Concerto board

Pablo,

is Concerto running TCP server or Client? what is the performace you are getting? Can you tell what is the bottleneck for performace hit here, I assume you are not sending any continuous bulk data out from Concerto and neither Concerto is receiving any bulk data.

Yes the bigger the window sizes and the lesser the RTT of packet is the better the performace will be, but your application looks simple - sending out UINT16 data at frequent intervals, so I cannot understand where the bottleneck is, may be I'm not completely understand the application or you are measuing performace for some other application and try to estimate it?

Best Regards

Santosh

Santosh,

thank you very much for such a fast response. About your questions:

1. Concerto is operating as a Client.

2. Performance we are achieving is: 4235294 bits/s

3. For our application we need to continously send data, keeping the transfer speed in a minimum of 5760000 bits/s. The bottleneck seems to be in the sending part, and particularly in the waiting for the ACK response (we still need to analyze the TCP packets in order to make sure on this). We are sure is not in the computer part as this has been tested extensively in previous applications.

4. The configuration we have is UIP_BUSIZE 1500 and each time we send data, 1152 bytes are sent.

From my previous post, please also indicate which is the best approach, to use uIP or lwip and in the first case, about expected performance using uip_split_output().

Please, let me know any additional detail you need in order to clarify were the problem is.

Regards,

Pablo

Pablo

Thanks for the details. You can use wireshark packet sniffing tools to analyze the TCP stream and see if the client is not transmitting packets fast enough. Normally if its the client then its because either the ACK is not received in time or the stack itself is written in such a way to transmit one packet at a time and wait for ACK and transmit another. The difference in the performance of what you have and what you need is not much. You can analyze the TCP stream to see if the stack is causing the bottle neck or the buffer sizes are small, you can try playing around the interrupt priorities depending on what else you have in your application, is the client application not transmitting the data because it doesn;t have the data to be sent or it has the data but it takes long time to get the data out of the device because of other high priority tasks and other data copies?

We don't have any recommendation on which one to use uIP or lwip, it depends on customers application and other things (interrupts, COMs etc) the application does and how much memory you have. I would suggest trying both and compare the performance.

Did you browse web to check for any bench markings on uIP and lwip stacks?

Best Regards

Santosh

Dear Santosh,

thank you very much. I was already using Wireshark in order to inspect the sent frames and was able to avoid the delayed ACK problem just by changing an option in the sock structure (linux):

setsockopt(sock, IPPROTO_TCP, TCP_QUICKACK, (int[]){1}, sizeof(int));

By doing that I have isolated the problem to the ratio between the UIP_PERIODIC_TIMER_MS constant and the size of the data sent each TCP frame. Still the problem is that I need to increase a lot the size for the internal buffers in order to reach the maximum allowed window size (1500bytes), but I am running out of memory, so I will need to optimize a lot the code.

About your questions on comparative benches between both stacks, I do not look on it. I will. Do you have some numbers on the maximum expected throughput based on any previous test?

Best regards,

Pablo

Pablo,

thanks, the delayed ack would normally help acknowledge more no. of bytes of data in a single ACK packet from server, so it should help the TCP throughput in a real scenario and also help avoid congestion by reducing no. of packets out on network. I'm not sure how UIP stack is written though if it keeps sending data until ACK is received or it waits for ACK before sending next TCP segment - now we are getting into the stack internals.

Do you know if the stack is using DMA? if not you might want to explore that option.

I wish I had some answer for the throughput test question, but we didn't run any tests because the throughput is always dependent on the application use case and memory.

Best Regards

Santosh

Santosh,

Again thank you for your swift reply. Because of the small memory footprint wanted in uIP, only one segment on the fly is allowed. This means that it will not send any new data before the previous one is ACK. So I think that for point to point applications the recommended configuration is the one I suggested in the previous email. For networks having much traffic or for a central server, is of course to increase congestion.

About DMA, I think just the moving to the Ethernet hardware registers is using it, but still need to take a look on that.

I however think the key aspect is how the stack is written (8 bit architectures) so a stack which really exploits the 32 bits would be needed (maybe just modify the existing one). I strongly recommend to look on that direction for future Controlsuite releases for the Concerto board, it is a little bit frustrating to have a fast communication hardware  but be hit by the software implementation.

I will keep running more test on this and see how far I can get. Hopefully the speed needed for our application could e reached. 

Best regards,

Pablo

Pablo

I agree with what you say and thanks for your suggestion. we will take the use case into account and see what can be done.

Best Regards

Santosh

Pablo,

Is there a reason why you're not using UDP? The lack of a handshake could speed things up.

I'm assuming you're on a local network, so packet loss should be almost nonexistent.

Cheers,

Alvaro

Alvaro,

We thought on that, but because of the  application goal we need to make sure there will be no even a single sample to be lost. Having said that, We are going to try, in order to test the behavior.

Regards,

Pablo

Pablo.

I believe the problem you are having is due to the ACKs. From what i have read, most PC/PLC based TCP stacks do not respond with an ACK when the packet first comes in, but wait to see if another packet in the stream follows in a short period of time. This save on network traffic for the ACKs and most TCP stacks support this. uIP and lwIP do not. They only send one packet at a time and wait for the ACK to sned another packet. Because the serversice does not directly respond with an ACK, that adds a delay into the packet handshaking.

I am looking into adding a TCP/IP stack to our 2812 hardware. I was considering lwIP since I have read that it is better than uIP, but really I'm sure either would work for my application. I really only need UDP comms and not anywhere near the rate that you quoted that you are getting.Would it be possible to get a copy of the code you are using? It would be nice to not have to start from scratch in porting a stack to the 2812.

Regards,

Clinton Parker