Re: [foxboro] FW: FW: More future direction questions.
- From: "Johnson, Alex P (IPS)" <alex.johnson@xxxxxxxxxxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Thu, 13 Oct 2005 16:03:33 -0400
And the answer is:
The ATS hides the Mesh network from the V7.x NFS. Thus, the presence or
absence of equipment on the Mesh has no impact on the design of the V7.x
node.
Does that answer your question, Neil?
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77063
+1 713 722 2859 (voice)
+1 713 932 0222 (fax)
+1 713 722 2700 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Johnson, Alex P (IPS)
Sent: Thursday, October 13, 2005 2:13 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: FW: More future direction questions.
Re: If we already have 4 Nodebus segments connected with NCNIs to the V7.X
switches, is adding a separate 1x8 loaded with NCNI's and ATSs to create a
5th Nodebus segment for interface to a new V8.X AW station and any CP270s
that we add (or upgrade to) going to be a Foxboro supported option? Stated
another way, when NCNIs and V7.X switches are used to interconnect the
segments, are 5 Nodebus segments allowed?
That's a really good question. One of the best I've had in weeks.
For those that do not know, V7.0 systems allow five (5) control segments in
a Node. A control segment is one that has control stations in it. A segment
with only WPs/AWs does not count as a control segment. WPs/AWs attached with
RCNIs do not count either.
Version 7.1 bumped the limit to eight (8) control segments in Node.
The limitation is imposed by our network fault detection software.
What Neil is asking is, "How does a large Mesh network impact this
limitation?"
Truth is - I don't know. (Man, that hurts.)
I'll have to ask and get back to you.
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77063
+1 713 722 2859 (voice)
+1 713 932 0222 (fax)
+1 713 722 2700 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Neil Martin
Sent: Thursday, October 13, 2005 2:04 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] FW: FW: More future direction questions.
Alex,
Thank you for taking the time to explain the options and thought process -
it does help us understand. However, for those of who already made a leap
to upgrading to NCNIs, and some V7.X AW stations and switches, the ATS
implementation is definitely a step backwards. FYI, my concern is not that
I have to install a V8.X AW by adding a new station or upgrading an older
station or software, I already new I would have to have at least one 8.X AW
station. And yes, I am hoping I can wait long enough for the Unix version
of 8.X to arrive.
If we already have 4 Nodebus segments connected with NCNIs to the V7.X
switches, is adding a separate 1x8 loaded with NCNI's and ATSs to create a
5th Nodebus segment for interface to a new V8.X AW station and any CP270s
that we add (or upgrade to) going to be a Foxboro supported option? Stated
another way, when NCNIs and V7.X switches are used to interconnect the
segments, are 5 Nodebus segments allowed?
Neil Martin, P.E.
Huntsman Polymers Corporation
2505 South Grandview
Odessa, TX. 79766
ph) 432-640-8436
pager)432-742-4289
email page)4327424289@xxxxxxxxxxxxx
"Johnson, Alex P
(IPS)" To:
foxboro@xxxxxxxxxxxxx
<alex.johnson@xxxxxx cc:
vensys.com> Subject: [foxboro] FW:
FW: More future direction questions.
Sent by:
foxboro-bounce@freel
ists.org
10/13/2005 12:44 PM
Please respond to
foxboro
Not sure that this got out.
Regards,
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77063
+1 713 722 2859 (voice)
+1 713 932 0222 (fax)
+1 713 722 2700 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
Re: We used NCNIs and the V7.X switches to replace the FONBEs in our 4
existing Nodebus segments. Besides allowing us to install V7.X stations,
this resulted in greatly reducing the traffic on our originally very
heavily
loaded single Nodebus system.
Good. I wish more people took advantage of this V7.x capability.
Re: Using an existing Nodebus segment to interface V8.X stations and any
CP270s to the V6.X/V7.X DCS portion of our system is going to raise the
Nodebus traffic impact on the Nodebus segment the ATS modules are installed
in and could likely overload it - it is a big step backwards for us.
I'm not trying to minimize your request. It's not unreasonable, but there
are reasons we did what we did and I'd like to present them so you can
understand what we were thinking when we designed a single ATS module as
opposed to two different ones.
So, here we go...
The various cases are:
1) Expanding a CBLAN network with a "new" Node of Mesh equipment
2) Moving a Node from a CBLAN network
a) V7.x Nodes
b) V6.x Nodes
3) Expanding a Node on a non CBLAN system
a) V7.x Nodes
b) V6.x Nodes
I believe that this is a complete set of cases. Now, I'll tell you how we
think the equipment fits the cases. As in any system design, loading must
be
calculated to ensure proper operation, but I think we have you covered.
Case 1) Expanding a CBLAN Network
Add a "bridge node" to the CBLAN Network. This Node consists of a 1x8
with just a pair of CBLIs and a pair of ATSs in it. CBLI is hosted by
a V7.x AW and ATS hosted by V8 AW70.
This option allows the "bridge node" to handle all traffic between the
Mesh and the CBLAN networks. In this configuration, there is
considerable
throughput.
As Nodes are migrated to the Mesh (using ATS), the load here should go
up
and then down to zero.
Case 2.a) - Moving a Node from a CBLAN Network for V7.x Nodes
Put the ATS and a NCNI into a dedicated 1x8 - This segment handles quite
a bit of throughput (1000 packets per second). This option is ONLY
necessary if the CBLAN's segment is overloaded which would be very
unusual. The disadvantage is the cost and space of the 1x8.
Or
Put the ATS in a relatively unloaded segment hanging from a V7 switch
usually the one which hold the CBLI. This is the nominal case. We
believe that the traffic from any one node to the mesh is unlikely to
overload a Nodebus segment segment since the CBLAN was handling it.
Case 2.b) - Moving a Node from a CBLAN Network for V6.x Nodes
Put the ATS into a Nodebus segment on where the CBLI was.
Since the CBLI's segment is functioning, using an ATS will not
make it worse.
Case 3.a) Expanding a Node on a non CBLAN system under V7.x
Put the ATS in a relatively unloaded segment hanging from a V7 switch.
This is the nominal case; we are assuming that the Node segmentation
has freed headroom on the segment.
It is important to note that the traffic isolation is retained
at both the ATS and the NCNI. That is, the only added traffic
in the segment holding the ATS is data that is supposed to move
into the Node. It is highly unlikely to overload a V7.x segment.
Case 3.b) Expanding a Node on a non CBLAN system under V7.x
If you have used FONBEs, replace them with NCNIs (a good idea
in any case) and add the ATS to the segment that sinks/sources
most of the data going to the Mesh.
It is important to note that the traffic isolation is retained
at the ATS. That is, the only added traffic in the Node is supposed
to move into or out of the Node. This situation is no different
than adding a CBLI in the "old days."
So, for larger expansions - and CBLAN replacements - we recommend a "bridge
node". For V7.x systems, we believe that most customers will have the slot
space and lightly loaded segments. For V6.x system, we believe that the use
of the ATS is no worse than the CBLI that was (or would have been) used in
the "old days."
At the end of the day, we think we made a reasonable decision for the vast
majority of the installed base.
Does this make sense?
_______________________________________________________________________
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
_______________________________________________________________________
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
_______________________________________________________________________
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
_______________________________________________________________________
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:
