EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: [Fwd: network storms and epics]
From: Geoff Savage <[email protected]>
To: EPICS Tech-Talk <[email protected]>
Date: Fri, 25 Feb 2005 07:55:37 -0600
Somehow this did not go through the list server yesterday.

Geoff

-------- Original Message --------
Subject: 	network storms and epics
Date: 	Thu, 24 Feb 2005 16:25:10 -0600
From: 	Geoff Savage <[email protected]>
To: 	EPICS Tech-Talk <[email protected]>



Hi,

Early Wednesday morning we had two incidents where misbehaving terminal servers were sending out broadcasts on our controls network (100 MB ethernet) at rates around 2 Mega bits per second for 5 minutes. I am in the process of upgrading the firmware on the terminal servers to eliminate this problem. The issue is that I don't fully understand all the alarms that were generated.

We saw CPU alarms on mv2301 and mv162 processors running epics 3.14.6 built with vxworks 5.5 using the vxStats v1-2 package. We did not see any alarms from mv2301 processors running epics 3.13.4 built with vxworks 5.3.1. So it looks like vxworks 5.5 does not handle network problems as well as vxworks 5.3.1. I seem to remember something about fixed network buffer sizes in the newer version. But why would this cause the CPU work harder?

Some (not all) of the processors with CPU alarms also had voltage monitoring records that went into alarm. We saw no other evidence that the voltages were out of range. In some cases the value that triggered the alarm condition was zero yet no power supplies reported a trip condition or needed to be reset. Is it possible for record scanning to get into a state during periods of high cpu usage that would explain the false alarms?

Thanks, Geoff



Navigate by Date:
Prev: Re: about dylight saving time Marty Kraimer
Next: SUMMARY: Flavors of Linux Gary P Carr
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: about dylight saving time Marty Kraimer
Next: SUMMARY: Flavors of Linux Gary P Carr
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·