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: "Ernest L. Williams Jr." <[email protected]>
To: Jeff Hill <[email protected]>, Dave Thompson <[email protected]>
Cc: "'Steve Lewis'" <[email protected]>, "'Zelazny, Michael S.'" <[email protected]>, "'EPICS Tech-Talk'" <[email protected]>
Date: Sat, 23 Nov 2002 09:46:34 -0500
Hi,




On Mon, 2002-11-18 at 12:04, Jeff Hill wrote:
> 
> >    -- 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)
> > 
> 
> A considerable amount of effort has gone into making TCP efficient. This
> is especially true in high throughput situations and in situations where
> there is network congestion. While similar things can be accomplished
> with UDP you are always at a disadvantage because TCP is scheduled
> within the operating system, and because TCP is so fundamental that is
> has had more research dollars thrown at it. Making and breaking TCP
> circuits is not particularly efficient, but after the circuit is
> established it is hard to beat. In contrast, I seem to recall that the
> implementation of NFS on vxWorks is resource intensive. It uses quite a
> bit of stack space, and it uses a lot of dynamically allocated memory.
> There is nothing inherently wrong with dynamic memory allocation on
> vxWorks. However whenever an action is running periodically that must
> repeatedly allocate and free memory then there may be concerns about
> memory fragmentation. I seem to also recall reading that NFS was not
> particularly efficient in wide area network situations because of less
> than optimal packet schedualing, but that may have changed in recent
> years.
> 
> I completely agree with the goal of distributing the system and thereby
> avoiding a single point of failure. However, the NFS server, while
> capable of some robust configurations, should probably not be entirely
> released from scrutiny when identifying single points of failure. 
> 
> In a perfect world, the backup and restore data would be maintained in a
> battery backed up RAM resident within the IOC. All other boot data would
> be maintained in a flash ram also resident within the IOC.
VxWorks has Flash File system support.  We will pursue this as well at
the SNS.




> 
> Jeff
> 



References:
RE: Channel Watcher V2.0 Jeff Hill

Navigate by Date:
Prev: Re: building R3.14 problem for RTEMS Till Straumann
Next: Channel Access/Linux/R3.13.7 Hammonds, John
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 Jeff Hill
Next: Re: Channel Watcher V2.0 Pete R. Jemian
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 ·