Innovate Motorsports OT-2 SDK - Manual (Page 69)

69
Special Considerations for Network/Wi-Fi
Although, in general, network programming with the OT-2 is straightforward, there are
some special considerations worth mentioning. Given the modest rate and volume of
MTS data, and the high bit rate of Wi-Fi in comparison, data throughput would not
normally be thought of as a potential problem. However, because of the way that TCP
works on many systems, it is.
Performance
The primary issue is that network stacks generally make some effort to minimize network
traffic. They often do this in a couple of ways that directly conflict with typical operation
of the OT-2. First, systems often let small packets accumulate before actually sending
anything. The method used is often some variant of something called the “Nagle
Algorithm”.
This works well at minimizing the number of small payload packets on the network, but
it adds unnecessary delays to the delivery of small commands, like those used in the
different modes of the OT-2. In other words, by default, you might send a ‘j’ command to
get connection status, but your computer’s network stack may decide to wait 200 mS
before actually sending it, on the chance that you might have more information to send,
which could all be put into one, larger packet.
Fortunately, this sort of buffering can normally be turned off. Search your operating
system reference for TCP_NODELAY. It is usually a “socket option” that is applied at
the “protocol level”. With the Nagle algorithm turned off, bytes are transmitted right
away.
However, another source of delay may remain. Again, in order to avoid small packets,
many network stacks (including Windows’) use something called “Delayed Ack”. In a
TCP packet, both data and handshaking information can be included. When the Windows
stack receives data it typically waits a brief interval before acknowledging the receipt of
the data. It does this in case the Windows side user has something to send in response. If
it does, the stack knows it could combine the data and the acknowledgement in one
packet, hence saving network bandwidth.
The problem with this is the sending side must wait for the acknowledgement before
sending more data. Because of delayed acknowledgement, data ends up coming in larger
chunks from the device side. From a network traffic point of view, this is a good thing.
But if you want to update your onscreen gauges, etc. quickly, then you do not want MTS
data packets, which are only about 12 Hz to begin with, coming in 2-3 at a time. This
slows your UI update to roughly ¼ of a second.
No data is lost, so this is not a problem for logging, but it can diminish the user
experience. There is not generally an easy way to turn this behavior off in the stack, but