Re: [foxboro] PI load to DCS

Thx Terry,
I'll "try" to follow theese tips... actually, it is tough.. :)

jaime

-----Mensaje original-----
De: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]En
nombre de Doucet, Terrence
Enviado el: S=E1bado, 25 de Marzo de 2006 11:00
Para: foxboro@xxxxxxxxxxxxx
Asunto: Re: [foxboro] PI load to DCS


Jaimie,
=20
Tough question!
=20
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
=20
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=20
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.=20
=20
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"=20
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=20
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. =20
This could be a critical time!
=20
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.
=20
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.
=20
You aslo need to look at free memory and largest free segment. See the =
books for limits on these as I cannot remember them.
=20
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.
=20
Hope this helps.
=20
Terry
=20
________________________________
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 =3D
affecting DCS ??
What I want to have is a "number" or "index" to decide not to put any =
=3D
more PI_tag and think in futher solution$$$.

We have an AW (unix P81) with PI interface, connected to mill LAN via =
=3D
2nd ethernet to PIserver. So all data from DCS goes through this port =
=3D
(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:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave




-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat


=20
=20
_______________________________________________________________________
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
=20
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
to unsubscribe:      =
mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
=20
 
 
_______________________________________________________________________
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:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: