Re: [foxboro] ATS and nodebus loading

Your frame counters and collisions are accumulators - how much are
they incrementing in 10 minutes?
The CBLAN modules were rated at 300 PDUS30 peak for short periods.
Nodebus with FONBEs was around 800 packets per second peak and without
FONBEs should have been around 1600 packets per second.  My
understanding was that the ATS modules are able to handle at least as
much traffic as the nodebus, and had been throttled to minimize the
possibility of overwhelming the nodebus.

Regards,

Kevin FitzGerrell

On Mon, Apr 28, 2008 at 10:42 PM, Joseph M. Riccardi <joe@xxxxxxxxxxxxx> wrote:
> 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
>
>
 
 
_______________________________________________________________________
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: