Nano is providing data packets to an intel processor via http request. Communication is over KSZ9896 network switch. If a network glitch occurs, for example temporary data disconnect, some processors require 1-2 seconds to reconnect and respond, while other processors require 6-7 seconds to respond. What could be causing this difference?
The Nano is residing on a custom carrier board. The operating system is a Yocto-created distribution.
I’m a long way from being able to answer that. However, to start with, most HTTP is over TCP (not UDP). This means it is likely TCP which is detecting loss of packets or packet reordering/out-of-order. The Nagle algorithm is responsible for resends and TCP has packet ordering; between packet reordering and Nagle you get all of your packets, and get them in the right order. Once the disconnect is detected, and both ends reconnect, then it is likely the protocol responsible for the rest of the unpredictable delay. To some extent this can be tuned, but most applications don’t do this; individual applications would likely need to tweak the TCP parameters. Don’t know for sure, but that’s a starting point.
UDP does not support retransmit, nor packet reordering. This won’t have the retransmit or reorder delays, and is probably a way to compare. I say this because if you perform testing of loss under both TCP and UDP, then the UDP should be faster. The time to restart activity of TCP which is beyond that of UDP is likely the protocol-dependent portion of your question (the base time of seeing UDP continue is probably part of the PHY and IP protocol).