MC9S12NE64

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: MC9S12NE64
If you cannot resolve your problem, you may want to check out CMX at
www.cmx.com.  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.


Re: MC9S12NE64

Quoted text here. Click to load it


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



Re: MC9S12NE64
Quoted text here. Click to load it

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.

Re: MC9S12NE64
snipped-for-privacy@gmail.com (Johnny Karlsson) writes:
Quoted text here. Click to load it

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

Thanks!
Eric

Re: MC9S12NE64
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


Re: MC9S12NE64
Quoted text here. Click to load it

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

Re: MC9S12NE64
Quoted text here. Click to load it

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
www.EmbeddedRelated.com

Re: MC9S12NE64

florian skrev:

Quoted text here. Click to load it

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


Re: MC9S12NE64
Quoted text here. Click to load it
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
www.EmbeddedRelated.com

Re: MC9S12NE64

Quoted text here. Click to load it


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?


Re: MC9S12NE64
Quoted text here. Click to load it

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
www.EmbeddedRelated.com

Re: MC9S12NE64

Quoted text here. Click to load it


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?


Re: MC9S12NE64
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
www.EmbeddedRelated.com

Re: MC9S12NE64
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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.


Re: MC9S12NE64
Quoted text here. Click to load it

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?

Quoted text here. Click to load it

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.


Quoted text here. Click to load it

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
www.EmbeddedRelated.com

Re: MC9S12NE64

Quoted text here. Click to load it

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);


Re: MC9S12NE64

Quoted text here. Click to load it

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.


Re: MC9S12NE64
Quoted text here. Click to load it
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
www.EmbeddedRelated.com

Re: MC9S12NE64
Quoted text here. Click to load it
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
www.EmbeddedRelated.com

Site Timeline