The PC never decreases the speed of the TCP reception because it can
buffer and process each TCP packet fast enough that the remote peer
does not notice it. This is achieved by keeping the TCP window
unchanged. A key behavior in a fully compliant RFC TCP stack is that
while buffering all received packets, a host can use a single
acknowledgement for several received packets. This is not the case for
OpenTCP.
OpenTCP sends an ACK for every TCP packet it processes successfully in
a sequential manner. Although the reception of each packet on the NE64
is performed on an interrupt context (or "foreground" context), the
actual processing happens using simple polling in the main loop. This
increases the latency of the stack. If both buffers (A and B) on the
NE64 are not empty (for example one of them is being processed and the
other stores a retransmitted packet), new receive frames are dropped
silently until one of the buffers becomes available.
By design under these conditions it is impossible for the NE64 EMAC to
know how many and what packets were dropped. All dropped packets will
re-appear on the network as retransmissions sooner or later and this
will cause the extra retransmissions and late ACKs experienced by you
guys.

>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

>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

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.

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

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

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