EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: NFS performance problems on vxWorks
From: Till Straumann <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Dirk Zimoch <[email protected]>, TECHTALK <[email protected]>
Date: Thu, 11 Nov 2004 11:21:49 -0800
Andrew Johnson wrote:
Dirk,

Dirk Zimoch wrote:


our vxWorks IOCs mount their boot directory, auto-save-and-restore directory and data aquisition directory via NFS.


Now, I noticed a very poor performance on several IOCs. Test

...

I have also observed this when comparing to a NFS client I wrote for the RTEMS (open source) RTOS. My client is simple and similar in performance (i.e., low perf.). This is mostly due to the lack of a buffer cache (read-ahead / delayed write) which could significantly increase performance. Maybe, vxWorks has no buffer cache either. It means that network I/O is essentially synchronous, implying a full RPC call for every read/write request!

You could try to only use buffered I/O with large buffers and
increase NFS packets (if possible under vxWorks) to the protocol
limit of <~8k. Try this + using stdio with a custom buffer
taylored to the NFS packet size (setvbuf(3)).

Till


When only vxWorks is running but not EPICS, it seems to be ok. If an empty EPICS (no records) is running, there few errors. The problem does not depend on the EPICS version (I tried 3.13.2 and 3.13.9). The idle time of the ioc is about 80%.


The NFS protocol version supported by vxWorks uses UDP packets for data transfer, and is not as efficient at handling dropped packets as TCP is. In your case, I suspect that your IOCs are dropping input packets from the network, which causes the 5 second NFS delays.

Since your IOC has lots of idle time available, you should be able to resolve this by just increasing the size of the network input buffer pool, which is usually one of the parameters in the vxWorks END configuration string - have a look in your sysEnd.c file [or wherever the xxxEndLoad() routine is called in your BSP] and increase the number of read buffers.

- Andrew



References:
NFS performance problems on vxWorks Dirk Zimoch
Re: NFS performance problems on vxWorks Andrew Johnson

Navigate by Date:
Prev: Re: NFS performance problems on vxWorks Andrew Johnson
Next: counting semaphore for 3.14.x Kate Feng
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: NFS performance problems on vxWorks Andrew Johnson
Next: Re: NFS performance problems on vxWorks Andrew Johnson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  <20042005  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 ·