To read the full content, please log in or register as an MLE Developer Zone Member.
4.1. Picking the “Right” TCP Peer MLE NPAP has a clear focus on highest performance in a very resource efficient FPGA implementation which is reliable (the key reason to use TCP) and interoperable with (almost) any other TCP/UDP/IPv4 stack. When you optimize data transports towards low latency and/or high bandwidth, keep in mind how both, TCP flow control and TCP congestion control, function and do parameterize both peers accordingly. NPAP runs the entire protocol stack as a digital circuit. So, when NPAP is on the receiving side, TCP packets will be checked, and acknowledged (ACK’ed), in a very short time and at a very high rate (close to line rate). That may challenge a “slow sender”. Similarly, when NPAP is on the sender side, TCP packets will be generated and sent in a very short time and at a very high rate (close to line rate). That may challenge a “slow receiver”. Experimenting, and tweaking parameters on either side, is key to delivering good performance. Predictable high bandwidth and low latency is typically delivered by a “balanced” TCP connection, for example by putting NPAP on both sides. When implementing so-called High-Speed Data Acquisition systems we do recommend investigating NPAP not only for sensor-side TCP/IPv4 acceleration but also for PC-side: 🌐 www.missinglinkelectronics.com MLE