I have noticed that it takes about 100ms before a message sent by the device is matched on the element. The response does not have a trailer, but the third and fourth byte contain the size of the payload, so the driver uses:
communicationOptions="makeCommandByProtocol;packetInfo:2,2,false"
As the size of the response is known, there shouldn't be any significant delay.
The following parameters make up the response:
<Param id="2">
<Name>IpHeader</Name>
<Description>IP Header</Description>
<Type>fixed</Type>
<Interprete>
<RawType>other</RawType>
<Type>string</Type>
<LengthType>fixed</LengthType>
<Length>2</Length>
<Value>0x000x0C</Value>
</Interprete>
</Param>
<Param id="3">
<Name>CommandLength</Name>
<Description>CommandLength</Description>
<Type>length</Type>
<Interprete>
<RawType>unsigned number</RawType>
<Type>double</Type>
<LengthType>fixed</LengthType>
<Length>2</Length>
<Endian>big</Endian>
</Interprete>
<Length>
<Content>
<Param>2</Param>
</Content>
</Length>
</Param>
<Param id="5">
<Name>Response</Name>
<Description>Response</Description>
<Type>read</Type>
<Interprete>
<RawType>other</RawType>
<Type>string</Type>
<LengthType id="3">other param</LengthType>
</Interprete>
</Param>
100ms doesn't sound like much, but the device does not support any bulk commands, so this 100ms adds up quickly when I need to retrieve data for over 1000 parameters.
I created a small driver and console application as tcp server to reproduce the result. The element and console application ran on the same server to eliminate network latency and system clock differences.
These are log lines from the application and element respectively:
2022/01/06 11:51:11.601 Send: Packet 3
2022/01/06 11:51:11.700|SLProtocol - 9816 - latencyTest|22476|CParameter::MatchParameter|DBG|2|-> Response new data (Packet 3) 000000 5061636B65 742033 Packet 3
What could reduce this delay?
I tried to reproduce the setup (with real communication instead of only internal) and see the following timings:
-Send packet:
SLProtocol sends at 07:46:15.649
SLPort sends at 07:46:15.662 (+13ms)
Outgoing packet in Wireshark seen at the same time
-Incoming packet:
Incoming packet in Wireshark at 07:46:15.664
Incoming retransmission packet in Wireshark at 07:46:15.688
SLPort receives at 07:46:15.721 (+33ms) ("ProcessIncomming" method)
SLProtocol receives at 07:46:15.737 (+16ms)
I also modified it to work with header-trailer and the timings are similar.
Response is seen in Wireshark at .119, SLPort at .194, SLProtocol at .209 ->90ms difference between seeing it in Wireshark and seeing it in SLProtocol.
The delay doesn't seem to be specifically related to using the length, as header-trailer has also a delay.
There is a fixed delay between transferring from SLPort to SLProtocol of 15ms (so sending a command and receiving the response is already a delay of 30ms in total). The other delay varies: TCP packets are not always acknowledged and can have an extra delay of 24ms. The question then is when does SLPort really receive the incoming packet from the OS, would the delay be there or would it be in the part between getting the data from the OS and logging it out.
I don't really see a possible alternative from driver side to improve the delay as working with header-trailer (which should be directly passing the data) is also having similar delays. When changing the response into one "next param" parameter (no header, trailer, no packet length) with a small maxReceiveBuffer which should flush the data every 15ms also shows similar delays.
Do you have a way to build a simple application in Python or another language that could replicate a serial command and receive and log the response to validate that the unit itself is not responsible for a substantial portion of this delay?
Hi Michael
Fortunately, the device did have a desktop application.
With Wireshark I was able to confirm it uses the same API and was able to manage up to 5000 packet transfers per second.
Release Note 32219 has been created to fix this issue, that should improve the throughput with 50ms.