MC9S12NE64

florian wrote:

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

> As i mentioned before, soc->receive_next seems to be false. Every second
> or third packet is retransmitted because sequence number check (in tcp.c
> line 1340) fails.
>
> I used the original FSOTCP_1.0, therefore the problem must be in every
> application where MC9S12NE64 is used as client.

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?

>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?
>
>

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

florian wrote:
> >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

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

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?

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

florian wrote:
> Is there any version of the OpenTcp out which has the TCP flow control
> implemented?

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.

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

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.

>Well, it has flow control - the window size it advertises corresponds
>to how much data it can accept.  

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?

>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.

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.


>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.

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

florian wrote:

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

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

florian wrote:

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

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.

>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.
>
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

>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?
>
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