My driver discovers this and annotates the "Live" JSON types with per-member readability.
1 Like
From: OPC UA Drivers: Sample Group Diagnostic Tags
Overload is calculated with the formula:
100 * (QueueDuration / ActualSamplingInterval)
If overload exceeds 100%, then requests are being sampled at a slower than ideal rate.
From the above, one can infer that an Ignition driver with active subscriptions will always be with Overload > 0.000…%.
No the statement "if overload exceeds 100%" is just wrong. Any overload, other than a random percent or two, means sampling is slower than the desired pace.
1 Like
I think that calculation is wrong in the documentation. I think it should be:
100 * ((ActualSamplingInterval - IdealSamplingInterval) / IdealSamplingInterval)
Agreed, assuming the actual sampling interval value isn't bogus.
Agreed. A metric that reports a value of "50%", which equates to "Tag group was busy polling for 50% of sampling interval", is a very useful metric.
Doesn't change the important detail that, based on IA docs, zero% overload is not attainable.
It is this, but ActualSamplingInterval is IdealSamplingInterval + QueueDuration, which becomes
(IdealSamplingInterval + QueueDuration - IdealSamplingInterval) / IdealSamplingIterval
which becomes
QueueDuration / IdealSamplingInterval
I think the multiplication by 100 is just to put into a percentage when displayed.
So then queue duration is the round trip time from the time the request is made to the PLC until the value(s) are returned?
No, it's the amount of time a ready-to-send request sat in the request queue because other requests were queued ahead of it.
The reason ActualSamplingInterval is QueueDuration + IdealSamplingInterval is an implementation detail of how our drivers do polling.
When a request finishes executing, it schedules itself to be inserted into the queue at +SamplingInterval ms in the future. In the ideal scenario, +SamplingInterval ms elapses, the queue is empty or nearly empty, the queue duration is ~0, and it gets de-queued executed ~immediately.
1 Like
Correct, with the bogus math.
My drivers process requests as fast as they will go, then sit idle when nothing is pending. Batches are submitted at the desired poll interval, timing starts there, and ends when that batch is finished. Ideally, that happens before the interval expires, so there's a brief idle period. In that case, overload really is zero. My driver diagnostic items report enough information to determine the amount of leeway present when overload is zero.
As Kevin notes, IA's drivers don't work with batches, so you cannot determine the available bandwidth for them. (That architecture also produces bigger disruptions on subscription changes.)
1 Like
So queue duration is more of an indication of how fast the driver/PLC are able to process the requests due to connection counts, CIP connection size, and capabilities of the PLC comms, etc and actual "lag" time from start to finish is more of QueueDuration + ResponseTime. And you're saying the tag gets added back to the queue after IdealSamplingInterval ms from when it was "processed" or dequeued. Meaning that technically the driver can never achieve true IdealSamplingInterval due to this "lag". I guess I was thinking more along the lines of how Phil says his driver works in that all tags for a tag group are queued up every IdealSamplingInterval ms and then really, if a tag is already in the queue, could be dropped because evidently at that point you're overloaded and not able to process it anyway. Then you'd start getting lag, but on a non-overloaded PLC would almost guarantee IdealSamplingInterval rates.
You should add ResponseTime too. Leaving it out is how Nick got ~1ms actual sampling interval for requests that were taking 30ms to execute.
1 Like
If a batch is still running when its interval comes due, the batch is deferred until the prior batch finishes.
Also, drivers cannot see tag groups. Just subscription pace. All tags at a given pace make a batch.
1 Like
Of curiosity:
...until future 'as-scheduled' interval? As in, if a request is already in the queue, don't add it again?
Or, queued up to execute immediately following last overdue batch completion?
This.
When the interval expires, there's a bit of synchronized code in the "batch" object that checks if running at that point. If not, it kicks off another run. If running, it sets an "overdue" flag and exits. The code in the "batch" object that collects stats also monitors pending requests, and when that hits zero it synchronizes and resets the "running" status. While still synchronized, it checks "overdue" and if so, kicks off the next batch immediately.
1 Like