Re: [foxboro] ATS and nodebus loading

OK, here is another country heard from with potential problems...
What are acceptable values?  B0700BP  does not offer any insight.  And none
of these numbers, except PDUS30, have any reference to time.
  omgetimp ATS006PDUS30 (packets thru ATS)                      24.4667
PDUs/second
  omgetimp ATS006DRMCAST (Dropped Multicasts)           335
  omgetimp ATS006TXFRAME
20792064
  omgetimp ATS006RXFRAME
24340545
  omgetimp ATS006COLLS
15157

Are the above numbers in the acceptable range?  Just how many DRMCASTs
(Dropped Multicasts) and COLLSs (number of times the primary port has
changed on the Mesh) are acceptable?


Joseph M. Riccardi, Inc.
DCS Services - Industrial Process Control
 
Joe@xxxxxxxxxxxxx
 
"To give real service you must add something that cannot be bought or
measured with money; and that is sincerity and integrity." - Donald A. Adams
 

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Boulay, Russ
Sent: Sunday, April 27, 2008 12:35 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] ATS and nodebus loading

David,
A few things....

The ATS can easily pass 1000-1500 pkts/sec Just because the ATS is capable
of that rate, the old nodebus is still the old nodebus. So you could easily
hammer the nodebus with constant rates above 500 pkts/sec.

One of the key loading considerations is Multicasts.
The ATS can handle 20 multicasts/.5sec before dropping them.
So, unoptimized displays, trends without dedicated historian names, api
calls that broadcast, etc could cause some issues.
You can use the omgetimp to get some key values from ATS.
  omgetimp ATS006PDUS30 (packets thru ATS)
  omgetimp ATS006DRMCAST (Dropped Multicasts)
  omgetimp ATS006TXFRAME
  omgetimp ATS006RXFRAME
  omgetimp ATS006COLLS

Lastly, what CP images are your old CP's running?
When an ATS is added to a node it becomes the NFD master.
If your old CP's are runnng images below those that ship with I/A 6.5.2 and
7.1.1 than they can be subject to nodebus islanding.
There is a QF that allows NFD to be shutoff in the ATS in those cases.

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On Behalf Of David Johnson
Sent: Sunday, April 27, 2008 11:11 AM
To: Foxboro@xxxxxxxxxxxxx
Subject: [foxboro] ATS and nodebus loading

Hello all,

Does anyone know how much data I can pass through an ATS onto the =

nodebus before encountering problems.  In preparation for an upcoming =

outage we are sending many (several hundred) values from a new FCP270 =

through an ATS to a CP40 on the old nodebus side.  Everything worked =

fine until last week. Each week we are passing more data through the =

ATS.  Now we are encountering occasional (3 times in the last week) =

smurf-outs on all of the operator displays of data coming from the =

old CPs.   So it is like this, I think.  FCP270 AIN (mesh side)-> OLD =

CP40  AIN(nodebus side) -> New Displays (mesh side).  This is making =

for a LOT of remote connections in the old CPs and everything gets =

passed through the ATS twice.  I'm guessing the nodebus occasionally =

gets swamped.  It's all temporary in an effort to move everything to =

the mesh, but I need to roll another 50-100 points like this (real =

world wiring issues) for the next two weeks without a =

catastrophe.  Any advice would be appreciated.

Regards,
David


-- 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:             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: