MC9S12NE64

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.