Re: [foxboro] PI load to DCS
- From: "Doucet, Terrence" <tdoucet@xxxxxxxxxxxxxxxxxx>
- To: <foxboro@xxxxxxxxxxxxx>
- Date: Sat, 25 Mar 2006 10:00:00 -0500
Jaimie,
Tough question!
The PI, or any data gathering program, affects
1. the host station of the program
2. the node communication
3. the source station of the C:B.P 's
1.
The AW host of the program is a multi-tasking operating system. It will do
what you ask it to do,
as fast as it can. But what else are you asking it to do and is any of that
time critical? As an example,
try formatting a floppy and also try to read a big file. The floppy formatting
slows you down. You can read the
idle time of the AW. You can even trend the idle time. Does any negative
happening for the AW coincide with
low idle time? If yes, you are over loaded.
As a general rule, I never want to see the AW idle time lower than 90% on a
regular basis. So if I ask it to do something
on a non-periodic basis (eg print a report) the idle time can drop, but if it
is doing its regular stuff, 90% is as low as I want to see it.
Otherwise it "feels" slow. But if all this station is doing is gathering the
PI data and it does this in a timely manner, then it is OK.
2.
To look at node communication, you need FoxWatch or a third party tool.
FoxWatch can tell you your "normal"
packets per second. The key is to leave room for abnormal activity or bursts of
communication like an alarm flood when some process
equipment fails, etc. There are some Unix tools on the AW that can tell you
what your AW is putting onto the node and receiving from the
node. So you could monitor these numbers with PI running, then turn PI off and
see what changes. But this only tells you what the AW
can see. Try calling displays on another station (WP) and see how fast they
come. Then turn off PI and see what the difference is.
This might give you a feel for node communications caused by the program.
Remember to test while the program is starting up and building lists.
This could be a critical time!
3.
The source station of the C:B.P has not usually been the critical item since
CP10's, Com15's and AB Station. The 30's, 40's, 60's and 270's have lots of
horse power and RAM. There are tools you can use.
As a general rule, you want zero compound processor overruns and zero OM
overruns. If you get counts here, when does it happen? If during an
engineering function like ICC work, maybe its OK. If you get overruns when
nothing special is happening, I'd say you are in trouble.
As another general rule keep the station load below 75% for 10's 15's and AB
Sta and below 80% for the other stations.
You aslo need to look at free memory and largest free segment. See the books
for limits on these as I cannot remember them.
There are also limits on total IPC's, SOURCE connections and OM LISTS that can
be affected by a program like PI. You need to use the rsom program and rsipc
programs to see if you are hitting (or close to) limits in these areas. Some
of this data can be historized, too or you can put it in a CALC block to store
the peak value.
Hope this helps.
Terry
________________________________
From: foxboro-bounce@xxxxxxxxxxxxx on behalf of Jaime Claramunt R. (Inforsa)
Sent: Sat 3/25/2006 8:30 AM
To: foxboro@xxxxxxxxxxxxx
Subject: [foxboro] PI load to DCS
Hi List,
Does somebody knows a way to "measure" load or how PI system is =
affecting DCS ??
What I want to have is a "number" or "index" to decide not to put any =
more PI_tag and think in futher solution$$$.
We have an AW (unix P81) with PI interface, connected to mill LAN via =
2nd ethernet to PIserver. So all data from DCS goes through this port =
(AW) to all others CPs.
Thanks
regards
Jaime Claramunt
INFORSA paper mill
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: //www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
Other related posts:
