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
<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: Channel Watcher V2.0 Jeff Hill
- Next:
Re: Channel Watcher V2.0 Pete R. Jemian
- 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
|