What is the relation between Scanclass Rate and it’s Avg Duration?
If the Scanclass status report says the avg duration for a specific Scanclass with subscription rate of 100ms is 220ms, shoud I adjust the subscription rate for such Scanclass?
In general, should I adjust the subscription rate at a higher ms with regards to the avg duration, or Ignition somehow manages this internally?
A scan class with a duration that isn’t near zero is usually one with Query or DB tags that are taking non-trivial time to execute. We generally recommend you move these to their own scan class.
These do not affect the update of OPC tags belonging to the scan class unless you are using OPC Read Mode. For OPC tags the scan class rate is just a hint used to tell the OPC server what sampling interval we want when subscribing. There is no execution or polling or anything else done by scan classes for subscribed OPC tags.
They are actually non trivial tags (expression) as you pointed out. There is nothing wrong… I was just wondering what Ignition does if the avg. duration exceeds the scanclass rate. The scanclass is a direct one, whis subscription mode.
I have another scanclass (with approx. 10k tags, subscription, 500ms rate, all opc tags, duration around 30ms)… the OPC Server is an Ignition OPC server on another computer. the CPU load currently around 40%. If I lower the rate for this scanclass from 500ms to 100ms, the CPU load ramps up to 100%. So the subscription rate must have some impact on the cpu cycles of the OPC Server computer. Interesting thing: going from 500ms up to 1s or 10s has no perceivable impact on the load, going below 500ms on the other hand, affects the cpu load a lot. 250ms: cpu load 40% -> 90%. Tags in this group don’t change frequently. But when they do, they might trip (1->2->1) in a matter of a fraction of a second, so I try to lower the rate as much as possible to catch this events and issue an alert.
Nothing 
Sure, lowering the rate is not free of consequences for the server. It will have to do more work. But that increase in work is not caused by an increase in polling requests from the client, it’s because now the server is polling its underlying devices and running its subscription polling interval 5x as fast.
If you want to see the impact of the subscription load on your (Ignition local) OPC server, go to the Devices’ status page, and examine the details for the device in question. Those load factors are directly related to your scan class rate.
Blockquote[quote=“Kevin.Herron, post:4, topic:43292”]
Nothing
[/quote]
Wouldn’t that accumulate threads in time 
Since this is a IEC 60870-5-104 driver it is not polling, it is reporting by exception, so I guess it must be the subscription polling which is monitoring 10k+ datapoints for changes every 100ms …
you mean the Status/Connections/Devices …
I only see the Name/Driver/Status columns (no Actions)
Maybe the driver is not fully implemented since I developed the wrapper for the IEC 60870-5-104 myself
To wrap it up, I would like to find out why the scanclass rate pushes cpu cycles up so badly when you go below 500ms (I know this is not a magical number…) but still when going from 10s to 1s to 500ms there is no perceivable impact. Below that, cpu cycles go up to 90% at 250ms and hit the roof at 100ms. Maybe there is some heavy gc going on and the jvm just can’t cope with it anymore… I have 10k+ datapoints, but no polling to the devices.
What version of Ignition is the client and server gateway?
7.9.7
and it’s the CPU of the server that goes up, which is running on a different machine than the client, right?
Yes, to show load statistics, you must implement the getPollingMetrics() method in your driver.
Right
OK, I’ll look into it and upgrade, thank you Phill
Right
It’s most likely because in 7.9.7 a scan class rate is used as both the requested Publishing Interval of subscriptions and the Sampling Interval for items belonging to that subscription.
Publishing Interval is essentially how fast a subscription periodically “evaluates” itself to see if any of the items that belong to it have data changes queued, which it gathers and reports to the client in a batch.
Sampling Interval is per-item and is a request to the server to sample the underlying data source at this rate. Not really relevant in your case.
The CPU usage is probably just the server struggling to run that subscription faster than 500ms.
In later versions of 7.9 the requested Publishing Interval may end up even faster than the rate. The idea being that with, e.g. items being sampled at 1000ms, you might want a Publishing Interval of 500ms so that you don’t have to wait as long to receive the value for an item that sampled just after that last Publishing Interval elapsed.
In 8.0+ the requested Publishing Interval is configurable.
I’ll upgrade the vm from 4 cores to 8 to see if it helps.
OK, I get it.
I’ve seen the property, now I know the use case
Thanks!
If you really want to dig into this hook a profiler up to the server and record CPU usage.
The other use case is to increase the queue size of each item, use a fast sampling rate, and a slow publishing interval.
In this setup you collect changes as quick as you like and report them in one bigger periodic batch later. Useful for bandwidth constrained connections between client and server.