EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Channel Watcher V2.0
From: Steve Lewis <[email protected]>
To: "Zelazny, Michael S." <[email protected]>
Cc: EPICS Tech-Talk <[email protected]>
Date: Sat, 16 Nov 2002 13:26:43 -0800

The Channel Watcher moves the save part of save/restore from the IOC to UNIX.

This an old subject.


The motivation for the "bumpless" IOC-based approach to save/restore is:

-- reduce to a minimum the upset caused by rebooting an IOC while it is being used in an operational facility

-- maintain strong EPICS architectural bias against single-point failures and central bottlenecks

-- minimize administrative work of synchronizing (multiple, differently formatted) lists of things about channels

Bumpless assumes:

-- an application suite such as BURT is used to manage grand collections of set-points for initiating and changing how the facility operates, either from a non-operating state or when shifting over

-- you have got NFS working well for the usual booting-up process on your IOCs.

Bumpless provides:

-- a very simple way to mark fields in your database as "bumpless"; just another attribute like PP or MDEL to be naturally managed by the knowledgeable application developer

-- it has a few parameters to trade off efficiency with network/IOC loading: how often to save/now much to "batch" saves

-- since the single, short file it uses is typically kept on the same file system where the database loads from, the success of the one more or less ensures the success of the other

-- VxWorks NFS uses UDP; all told there is not much overhead. (CA, which is very efficient in most respects, uses TCP; and Channel Watcher may be additionally using NFS to access the file system from whichever host it is actually runnning on)

-- it is a very small amount of code; it is easily configured in to the IOC initialization; it does not require management of yet another central client service (get/build right code version; make sure it starts/restarts on some server; make sure its to-do list is updated when *ANY* IOC database is changed)



Disclaimer: I had a lot of involvement with getting the bumpless capability going (although Bob and Carl and a few others did all the work); and I am working with a very large non-EPICS control system in which almost everything depends on central servers/services.


Replies:
RE: Channel Watcher V2.0 Jeff Hill
References:
Re: Channel Watcher V2.0 Pete R. Jemian

Navigate by Date:
Prev: how about using a new IOC host OS? M.C.Shao
Next: building R3.14 problem for RTEMS M.C.Shao
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  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: Channel Watcher V2.0 Pete R. Jemian
Next: RE: Channel Watcher V2.0 Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  <20022003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·