Experimental Physics and Industrial Control System
>Operator response is a high priority requirement for all screens, and there
>are too many to keep up all the time. To address your concern, and still
>keep the performance, there are two solutions:
>
>1) move name resolution off to another (redundant) process on Unix; probably
> configurable so those who don't want to manage their namespace don't have
> to.
>2) use the CA gateway to front most or all clients, and have the gateway
> have LONG timeouts on dropping an unused channel. This unloads most of
> the connect and monitoring load off of the ioc, making it more real
> time
Here are a couple more options for those that find themselves "CPU
challenged" ...
1) If the CAMAC device support does not support "I/O Intr" scanning
of records, it should. In the Allen Bradley device support, one can
set
the binary records to I/O Intr and the records will only process when
that
input (or any other on the same I/O card :{ ) changes. If these
records happen to be linked to others, the # of records scanned per
second can be considerably reduced.
2) GO TO 3.13 IMMEDIATELY. There is this fantastic capability added in
3.13 that allows records to only be processed when an input PV
changes. All those records that have input links to records on other
ioc's can use this and they will only be processed when the source
PV changes. With prudent use of the mdel field, record processing
can be SUBSTSANTIALLY reduced (your mileage may vary due to your
specific circumstances). The other BIG WIN is when an input record
forward links to a large chain of records. IN 3.12, all records in
the
chain are processed everytime. With prudent (hmm, this word seems to
come up alot) application of the new CP link attribute, each record
will only get processed when its input value(s) change. Once again,
your mileage may vary, but for large, heavily linked, heavily binary,
periodically executed databases, the impact is likely to be
significant.
Ned
- Replies:
- Re: flaky IOC problems at Jefferson Lab Jeff Hill
- Navigate by Date:
- Prev:
Re: PC/WIN32 Display Options Mark S. Engbretson
- Next:
PROFIBUS vs CAN SIBLEY
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: flaky IOC problems at Jefferson Lab watson
- Next:
Re: flaky IOC problems at Jefferson Lab Jeff Hill
- Index:
1994
1995
1996
<1997>
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024