Hi Dojo
We are experiencing slow element behavior on a DCM element. In order to narrow down where the issue is located, we bypassed the current automation script that was doing element configurations and tried the sets directly on the element using the multiple set.
Once we pushed the sets, we noticed that the information events only show that the element “receives” these sets with huge delays in between. As shown below, the first set arrived fast, then it took about 2 min before the next set shows up. the 4 sets together seem to have taken over 3 min to arrive on the element. and also to reflect on the read parameters that show the actual values.
Looking at this piece of info: Data ingest & control plane: Internal flow – concept – DataMiner Dojo
QUESTION: Is it correct to state that the information event will only show that the set was reached, once the SetParam-thread (SLDataMiner) has execute this SET from it’s queue?
I hope with some feedback that we can continue our investigation in the best possible direction.
Thanks for your help.
Hi Thijs,
The information event “Set by XXXXX to XXXXX” gets generated by the SLProtocol process when it handles the parameter set command.
In your case, the SetParameterThread in SLDataMiner will have had a queue of 4 set commands. These are sent to SLProtocol one by one, and generate their information event when it is their turn to execute.
The main guess for the delays here would be slow handling or locking inside of SLProtocol or driver logic.
Thanks for this confirmation Wouter, we will further explore/investigate where the bottleneck is located within the protocol logic.