You can confirm that this behavior is affecting your application by tracing the round-trip communication time in WireShark
. After collecting your trace of the behavior, open your trace in WireShark and navigate to Statistics->Conversations
on the WireShark toolbar to access packet conversations between your host and slave device. select a conversation which communicates with your NI-XNET port (in our case, it is port 31415), and click the Graph
button in the lower right hand corner.
On the graph that appears, set Type in the lower left hand corner to Round Trip Time, and observe the graph - you can cycle through communication streams using the Stream control in the lower right hand corner if the behavior isn't present on the default zero stream.
The graph above shows NI-XNET communication time spiking up much higher than the stable speed during stalls, and down to zero during the rushes. If your communication graph exhibits a similar pattern to the graph shown above, then you are likely experiencing the stalling/rushing issue described in this article and could resolve your issue using the steps in the Solution section.