I/NET Configuration Status parameters: Processor Loading and LAN Loading (Percentages (%))

[Product_Support]

Issue

Processor % Loading and LAN % Loading; What do these mean and how can they impact my system.

• Processor % Loading -  This field displays the Controller processor (CPU) percent loading (0–100%). This number is an indication of how busy the controller is. 
• LAN % Loading - This shows the percentage of controller LAN communication attributable to this controller only. It is not the total control LAN loading figure.

Product Line

TAC INET

Environment

ALL I/NET Controllers (Controller LAN (CLAN) based)

Cause

A greater understanding of the values seen at each controller can greatly assist in having a more efficient I/NET network.

Resolution

The controller Processor % loading and LAN % loading are available from each controllers' configuration/status editor.

• You must be connected to the controller in order to use this editor. This information can also be obtained using the hand-held console, Code 3 (CPU %), and Code 4 (LAN %).
• These fields are display only. You cannot make changes. However, you can make changes to the database and observe the relative loading statistics after.
• The readings should be taken with all graphic pages and DCU controller point summaries closed.

Processor % Loading

This field displays the Controller processor (CPU) percent loading (0–100%).  This number is an indication of how busy the controller is.  If this number is 100, control actions may be lost or delayed.

You should not let this reading go above 80%.  If kept to below 80% then if the processor peaks for some reason, it has 20% to peak in without locking up for a number of processor machine states.

The conditions that affect the processor loading are as follows:

1. Resident Point scan interval.  All resident points are processed by the firmware.  If you find that the processor loading is high, then edit all the AOs and DOs that do not have a calculation extension and adjusting the scan intervals to 255 seconds.  In heavily populated controllers this will bring down the processor % loading somewhat.
2. Calculated Point frequency.  All resident points with a calculation extension will have their calculation processed at the scan interval of the target point.  If you find that the processor loading is high, then, on the calculation extensions that perform less important tasks, you may edit the target point’s scan intervals to a larger figure.
3. Event Initiated Sequences.  A number of sequences that are in a loop, that is to say, running sequences with a skip back to themselves causing the sequence to run continuously, will cause the processor % loading to rise.  Edit and modify to create a more efficient database.  Ensure that a minimum of 1-second delay is implemented between each action within a sequence.  Do not leave all actions at the default value of zero.  
4. DDC Module Sample Interval.  All DDC modules are processed at their respective sample interval.  If you find that the processor loading is high, then, on the DDC modules that perform less important tasks, you may edit the DDC module’s sample rates to a larger figure.
5. Global or Indirect Traffic.  Naturally, large quantities of global and or indirect traffic to and from the controller will cause the processor % loading to rise.  See the next section “LAN % Loading” for more details.
6. Graphic Pages and or Controller Point Summaries.  Graphic pages and or controller summaries with large quantities of points requesting information/data (solicited messages) from a controller will cause the processor % loading to rise.  This also includes the number of pages open either on the one host or multiple hosts.  You have a number of choices here; you could increase the host’s “Monitor Refresh Interval” to minimize the solicited traffic or you could rationalize the graphic pages to a more efficient use of points.
7. Alarm or Messages.  Large quantities of alarm or message traffic (unsolicited messages) from the controller will cause the processor % loading to rise.  You will have to identify the cause.  Be aware just taking out the matching message masks from the host or from the point will not inhibit the message from transmitting to the LAN, the Resident Point’s Message and or Alarm priority must be set to “None”.
8. SEVENTRENDS Data Uploads.  Large quantities of SEVENTRENDS data (unsolicited messages) being uploaded to the LAN from the controller will cause the processor % loading to rise.  You will have to identify the origin and alter the “Cell Sample Counts” and or the “Sample Control Interval” to relieve the condition.  Be aware just taking out the Host SEVENTRENDS Cell mask or the point’s Trend Sample SEVENTRENDS Distribution Mask will not inhibit the data from transmitting to the LAN, the SEVENTRENDS Distribution Priority must be set to “None”.

 LAN % Loading

This shows the percentage of controller LAN communication attributable to this controller only.  It is not the total control LAN loading figure.  Treat the control LAN as a 100% resource.  If this controller has a LAN percent loading of 23%, then the control LAN has only 77% of resources left to service the other controllers on the control LAN.

Another way to look at it is, in the above example, out of every 100 token passes on the control LAN this controller has used the token 23 times.

The best scenario is to have the lowest figure possible, e.g. 0%.  Just imagine a control LAN with 25 controllers connected, each controller with a ‘LAN % loading’ of 5 %.  The LAN is flooded and will cause messages to be lost and or buffered, graphic pages will not update as expected and the system will dramatically slow down.

The empirical rule is as follows: The ‘LAN % loading’ is allowed to rise to a figure above 0%, but within 20 seconds, it must go back to 0%.

The conditions that affect the ‘LAN % loading’ are as follows:

1. LAN Reconfigures.  Every time a LAN reconfigures all global points in every controller on that control LAN transmit their values on to the LAN, and all indirect points request, at their scan interval, an update from their associated global points.  On an unstable control LAN, this could contribute heavily to a controller’s ‘LAN % loading’.
2. Global Point Traffic.  Large quantities of global point traffic from the controller will cause the ‘LAN % loading’ to rise.  The conditions that affect the frequency of global traffic are:
   1. Global point’s “Broadcast Change Counts”.  Remember that multiplying the analog point’s conversion coefficient’s ‘m’ value with the broadcast change count value will be the resolution of the analog value to be exceeded to cause a broadcast onto the LAN. Just imagine a globalized analog point with a ‘m’ value of .05 and a Broadcast Change Counts set at 1.  Then this sensor will globalize its value every time the value exceeds 0.05 creating globalized traffic.
   2. The faulty sensor being globalized.  The sensor’s value being unstable to the extent that the point’s value changes exceed the “Broadcast Change Counts”, in extreme cases creating globalized traffic.
   3. Controller’s Power Line Frequency, HHC function [Ctrl 92], not set correctly.  This is for setting a notch filter to filter out power supply noise being imposed over the sensor’s input signal thereby helping to eliminate the sensor’s value appearing to fluctuate.  These fluctuations could send a global sensor’s value change to exceed the “Broadcast Change Counts” in extreme cases creating globalized traffic.
   4. Pulsed Input (PI) points.  The PI points “Scans between Broadcast” incorrectly assigned.
      Beware: a PI point with a “Scan Interval” of 1 second and a “Scans between Broadcast” set at 1 second will cause the controllers ‘LAN % loading’ to rise by 10% and stay there, even though the PI point’s value may not have changed.
3. Indirect Point Traffic.  Large quantities of indirect point traffic from the controller will cause the ‘LAN % loading’ to rise.  The conditions that affect the frequency of indirect point traffic are:
   1. LAN Reconfigures.  Every time a LAN reconfigures all indirect points, at their scan interval, request an update from their associated global points.  On an unstable control LAN, this could contribute heavily to a controller’s ‘LAN % loading’.
   2. Indirect Point scan intervals set incorrectly.  If an indirect point does not see a change in its state/value from the global point after 2 scan intervals then the indirect point will request an update from its associated global point to be reported at the indirect point’s 3^rd scan.  With global points that are reasonably static, i.e. not altering a lot e.g. status points, etc., the associated indirect points will carry out their requests for updates.  Therefore the indirect points scan intervals should be staggered system-wide, not just controller-wide.  If all the indirect points have the same scan interval they could conceivably request at the same time and queue and hang onto the control LAN’s token.
4. Graphic Pages and or Controller Point Summaries.  Graphic pages and or controller summaries with large quantities of points requesting information/data (solicited messages) from a controller will cause the ‘LAN % loading’ to rise.  This also includes the number of pages open either on the one host or multiple hosts.  You have a number of choices here; you could increase the host’s “Monitor Refresh Interval” to minimize the solicited traffic or you could rationalize the graphic pages to a more efficient use of points.
5. Alarm or Messages.  Large quantities of alarm or message traffic (unsolicited messages) from the controller will cause the ‘LAN % loading’ to rise.  You will have to identify the cause.  Be aware just taking out the matching message masks from the host or from the point will not inhibit the message from transmitting to the LAN, the Resident Point’s Message and or Alarm priority must be set to “None”.
6. SEVENTRENDS Data Uploads.  Large quantities of SEVENTRENDS data (unsolicited messages) being uploaded to the LAN from the controller will cause the ‘LAN % loading’ to rise.  You will have to identify the origin and alter the “Cell sample counts” and or the “Sample Control Interval” to relieve the condition.  Be aware just taking out the Host SEVENTRENDS Cell mask or the point’s Trend Sample SEVENTRENDS Distribution Mask will not inhibit the data from transmitting to the LAN, the SEVENTRENDS Distribution Priority must be set to “None”.