Optimizing Communications

As the ABMLXEIP driver is a front-end/back-end driver, there are no transport delays when processing read requests between Plant SCADA and the driver cache. If many requests are being serviced simultaneously, the CPU of the I/O Server may be pushed to its performance limitations.

This may lead to communication problems, evidenced by #COM appearing occasionally on graphics pages, or "Command canceled" errors appearing in the Kernel Window.

If this is happens, you can tune the driver throughput to help manage the resources of the I/O server. The standard driver parameters you can use to achieve this are MaxPending and Delay.

MaxPending limits the number of requests handled simultaneously, and can be used as follows:

[ABF1FD]MaxPending=x

where:

x = the maximum number of requests the driver can service simultaneously.

You can also implement a time delay to steady the flow of requests to the driver, rather than having them sent in bursts. The standard driver parameter Delay can be used as follows:

[ABMLXEIP]Delay=x

where:

x = the time delay (in milliseconds) between the delivery of each message.

The two can be used in tandem to maximize the number of requests managed simultaneously, while improving system stability.

Examples

[ABF1FD]MaxPending=1

The above example would mean the driver would service just one request at a time, and would wait for a reply to each request before the next one is sent.

[ABF1FD]MaxPending=256

The above example would mean that the driver is capable of servicing up to 256 requests at the same time. This means up to 256 requests can be sent before waiting for a response.

[ABMLXEIP]Delay=20

This example would result in a 20 millisecond delay between each request sent, slowing the rate of delivery to a manageable pace.

Note: MaxPending=1 would make the Delay parameter redundant, as only one request would be handled at a time.