MC9S12NE64

Hi, I'm using the MC9S12NE64 with the Freescale version of OpenTCP and I'm having some problems the the tcp/ip-stack. It sometimes doesn't ACK received data packets, which results in retransmissions. The problem doesen't seem to be related to high volume traffic all, tough the problem becomes more acute when a lot of data is being received and transmitted. Is someone using this tcp/ip-stack and having the same problems as me? I would also be interested in other peoples experiences with OpenTCP.

Best Wishes

Johnny Karlsson

Reply to
Johnny Karlsson
Loading thread data ...

If you cannot resolve your problem, you may want to check out CMX at

formatting link
CMX offers a small TCP/IP stack called CMX-MicroNet that works quite well on the MC9S12NE64 and is fully supported, etc. A free evaluation version of the software for this chip can be downloaded from the CMX website, as well.

Reply to
embeddedsys999

Mine is running in Uip....

but only 7Kb/S from MMC card for each conenction :(

but it kan handle 10 connections a 7Kb/s..... (caused by windowze is quite slow to ack)

Kasper

Reply to
Repzak

I found the the problem now, it was a bug in OpenTCP, i sent a patch to the maintainer of Freescale OpenTCP so hopefully the fix will be integrated in the next release. 7Kb/S seems really slow if your using the MC9212NE64, i can't give you a speed mesurement for OpenTCP but it seems faster then that.

Reply to
Johnny Karlsson

If it's a reasonably small patch, could you just post it here for the rest of us?

Thanks! Eric

Reply to
Eric Smith

Could you please explain what was the problem and how to fix it? that would be very helpful for us that are working with OpenTCP on NE64.

Thanks

Reply to
ReneT

Ok, i'll try and exlain it here, i could make a patch if you want me to. This applies to the latest Freescale OpenTCP(FSOTCP_1-0.tgz) release.

In the tcp.c, function process_tcp_in(), line 1335 we have this return statement. "return(0); //jpw added per steve testing". This return statement is used when a ack is received when we are in Connected mode. The problem with that is if the received package contains both data and ack then the data gets discarded. So removing the line "return(0); //jpw added per steve testing" solves the problem.

This does cause the possibility that a DATA event in the event handler function may happen even when there is no data. But i guess that it should be possible to recieve empty data packages. If not then it easy to check before issuing the data event if the len variable is bigger than zero.

//Johnny

Reply to
Johnny Karlsson

Hi, I'm also using the MC9S12NE64 with the OpenTCP from Freescale and I' haveing some Problems with the ACK. It sometimes ACK received data with a old sequence number and therefore there are a lot of retransmissions. Th problem is independent from traffic. It seems that soc->receive_next wil not be incremented correctly.

Does someone know about the problem?

Best Regards,

Florian Eibensteiner

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

florian skrev:

Hi, this could be related the the bug i reported. Please try the recommended solution i posted. If that doesn't work the perhaps your could post some more detailed information about the problem.

Best Regards

Johnny Karlsson

Reply to
johnny.karlsson

and

I'm

an

The

will

Hi,

i have removed that statement but it doesn't help. Your patch enable receiving data packets without the PSH flag, but the software on the p always sets this flag.

As i mentioned before, soc->receive_next seems to be false. Every secon or third packet is retransmitted because sequence number check (in tcp. line 1340) fails.

I used the original FSOTCP_1.0, therefore the problem must be in ever application where MC9S12NE64 is used as client.

Best Regards

Florian Eibensteiner This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

Are you sure you aren't just trying to feed the little guy packets faster than it can handle them, such that it is acking an older packet it actually paid attention to, while ignoring the most recent one sent (so that it will be retransmitted at a later time when it can be dealt with)? What the is experimental setup where you see this? What is generating the data, and how are you detecting the problem?

Reply to
cs_posting

i'm generating the data with an pc application under windows xp. thi application send data to the MC9S12NE64 and measure the time to benchmar the embedded stack. i use packetyzer for sniffing the network traffic an so i found out that there are many retransmissions.

Maybe the windows stack is to fast but how can i slow down it? Because i doesn't matter how fast the application is because the stack cause retransmissions if the ack comes to late. This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

Can you post a snippet of the analyzer log? Say everything between two succesfully transmitted & acknowledged packets?

This could be a bug, but it could also be a case of a very pipelined approach to communication that makes sense for "big" computers matching suboptimally, but still workably, with a more spartan appraoch needed for tiny ones. Dropping packets and forcing retransmission isn't illegal. I'm curious if it's really sending acks with the wrong number, or if it's correctly acking an older packet as a result of not being able to maintain a pipeline the way windows can.

You do know about the latency problem the other way, right? How something like windows TCP will tend to wait 200 ms to ack a packet from the NE64 if you only send them one at a time (as you must with a single packet buffer), so you have to trick it with extra acks?

Reply to
cs_posting

Is there any version of the OpenTcp out which has the TCP flow contro implemented?

Does someone have benchmark or performance values of the OpenTcp stack?

Best Regards,

Florian Eibensteiner This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

Well, it has flow control - the window size it advertises corresponds to how much data it can accept. What it doesn't have is support for multiple outstanding packets - there's little reason to write that as there isn't enough buffer memory to handle them. For example, on sending, you have to keep a packet in a buffer until it has been acknowledged because you might have to resend it. You can only support having multiple outstanding packets if you have enough memory to keep them around until they are acked.

Though, if you are sending lots of short packets it could be worth doing this even with limited buffer memory. Perhaps one of the non-free stacks for the NE64 handles this.

This can be misleading... often times the speed is not determined by the stack or the embedded chip, but by the willingness of the device on the other end (your windows PC) to work in a way compatible with a size limited implementation.

Reply to
cs_posting

I'm using the FSOTCP_1.1 but there is no flow control. The window size i independent from remote window or applicaiton buffer size. Which version do you use?

If the ethernet buffers are 1k and the packet size is not too big, it' not really difficult to implement a buffer mechanism to enable the stac for multiple outstanding data.

I know and the bottle neck, in consideration of performance is in mos cases the delayed acknowledgement. If two devices communicate togethe without delayed ack or if delayed ack is deactivated OpenTcp speed is u to 1.4 Mbps.

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

Yes, so one option would be re-writing it to handle delayed ack by keeping more than one sent packet buffer around.

Another is to cheat and after every sent data packet just send something useless like a redundant ack, using the little control packet buffer (which is seperate from the data packet buffer). For example:

soc = &tcp_socket[sockethandle]; soc->myflags = TCP_FLAG_ACK; tcp_sendcontrol(sockethandle);

Reply to
cs_posting

I've been thinking about this more, and it really doesn't seem like it would be that hard to do. The reason I hesitate to dive into it though is that I don't feel like I have something on hand that could generate the kinds of error condititions I'd need to feel confident that it worked for real - for example, I'd want to test it in a situation where it gets an ack for the last packet it's sent, but not one of the previous outstanding ones, in order to make sure that it can properly resend from all the buffers.

Reply to
cs_posting

I thought baout the problem and i think the only efficient way is to sen two or more frames and then wait for the ack - the sender is able to ac all sent bytes with one ack - and if there comes no ack or not all byte will be acked you have to retransmit all outstanding packets. There is way to make a selective retransmission it is described i RFC 1106 but think it's to heavy for a microcontroller.

I think with a possibility to send more then one packet a time performanc will be increased very well so that some useless retransmissions doesn' matter.

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

You are wright. I think the problem occures because opentcp cannot empt the emac buffers fast enough and so some packets are dropped.

If i use my pc and i think the windows stack is fully RFC compliant th congestion avoidance algorithm have to slow down the speed to decrease th number of retransmissions. But the pc never slow down the speed.

Does anyone know something about this problem?

This message was sent using the comp.arch.embedded web interface o

formatting link

Reply to
florian

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.