Re: [foxboro] Block resource usage listing

The queries to all FCMs happen at once.

But all FCMs do not acquire their data in the same amount of time. The more
FBMs under an FCM the longer it takes to get all the data to the FCM.

The CP waits a certain amount of time to get the data from each FCM one at a
time. If the FCM is busy/not ready, the CP waits and retries.

The time for an FCM to retrieve data is proportional to the number of FCMs,
but there is variance between FBMs according to the time of FBM and other
items.

Anyway, the query for data is done in parallel. The retrieval of data is
serial. Short chains first (or equal chains) minimizes retries by the CP.


FCMs are slower the FBIs because they read the message. The FBI is not
intelligent; it's an electrical isolator.

Regards,
 
Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (operator)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
http://www.invensys.com/Archestra.html.
 

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx] On
Behalf Of Corey R Clingo
Sent: Monday, April 19, 2004 4:05 PM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Block resource usage listing

It mostly makes sense, except for a couple of things.
If the FCM is just slower than the old FBIs, is the increased "waiting" 
the CP does on the FCM counted against its idletime?  I can understand the 
I/O processing time going up, but not the CP idletime.

And the part about configuring FCM ECBs from shortest to longest doesn't 
compute yet either.  The FCM configuration order having a performance 
impact implies to me that when an FCM ECB is processed, all the requests 
for FBM ECBs on that FCM's chain are sent.  If that is correct, and the 
ECB processing is on a fixed cycle, then either of two things happens: the 
FCM ECB requests are all issued rapid-fire, without waiting for a response 
from one FCM before moving to the next, or the CP waits for a response 
from each FCM before issuing a request to the next FCM.  If the former is 
occurring (a better approach, from where I sit), then FCM ECB order makes 
no difference; each FCM gets the same amount of time (1 cycle) to respond 
to the request.  If the latter is occurring, doing the shorter-chain FCMs 
first does prevent them from getting delayed into the next cycle by a 
longer-chain FCM overrunning, but doesn't give the longer-chain FCM more 
time; it still gets one cycle before another request is issued.

Thanks for the pointer on the spreadsheets.  I'll look in the formulas and 
generate a list.

Corey Clingo
BASF Corp.






"Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
04/16/2004 01:49 PM
Please respond to foxboro

              To:  foxboro 
              cc: 
         Subject:       Re: [foxboro] Block resource usage listing






There are CP Sizing spreadsheets for all CPs. They should meet your needs..

By the way, the CP40 vs. CP60 is typical IF there is one I/O chain.

I/O processing in a CP60 through an FCM is slower than in a CP40.

Why?

Simple, the FCM slows it down.

On the other hand, if you split your I/O across a number of FCMs, the
increased parallel operation will improve performance.

Even more improvement is possible, if you configure the ECB blocks for the
FCMs to be shortest chain to longest chain. This gives the more heavily
loaded FCMs time to complete without the CP having to ask again.


Make sense?

Regards,

Alex Johnson
Invensys Systems, Inc.
10707 Haddington
Houston, TX 77043
713.722.2859 (voice)
713.722.2700 (operator)
713.932.0222 (fax)
ajohnson@xxxxxxxxxxx
For the latest information on ArchestrA, go to
http://www.invensys.com/divisions/Archestra.html.






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