EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: RE: IocLogInit pu consumption (who to blame)
From: "Jeff Hill" <[email protected]>
To: "'Andrew Johnson'" <[email protected]>
Cc: "'Gasper Jansa'" <[email protected]>, "'Tech Talk'" <[email protected]>
Date: Mon, 11 Sep 2006 18:14:26 -0600
> I would therefor suggest that getting an ENETUNREACH should be grounds
> for completely aborting the log client startup process, rather than just
> trying the connection again later with the same address.

My understanding is that the routes _can_ be dynamically updated at any time
on most OS so it's probably reasonable to keep trying in case the problem is
going to go away. For example, the user might connect the system's modem to
an ISP, and this might install a new route. The connect retry poll rate
should of course be set slow enough so as to introduce an insignificant
load.

Jeff

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, September 11, 2006 12:18 PM
> To: Jeff Hill
> Cc: 'Gasper Jansa'; 'Tech Talk'
> Subject: Re: IocLogInit pu consumption (who to blame)
> 
> Hi Jeff,
> 
> thanks for the response.
> 
> Jeff Hill wrote:
> >
> > Typically, the socket connect system call will block the calling thread
> > should the connect attempt be unsuccessful, but apparently if there are
> no
> > local routing options the call fails out immediately (without suspending
> the
> > thread for any amount of time) opening up a CPU consumption
> vulnerability
> > because the code as written attempts to connect again immediately. The
> fix
> > will probably be a delay inserted where the socket connect attempt fails
> > (prior to rejoining the loop sustaining the connection attempts).
> 
> I can see two scenarios that might result in getting an ENETUNREACH
> status:  A) There is a temporary network routing problem which will get
> solved at some point in the future, and B) The user put the wrong
> address into EPICS_IOC_LOG_INET.  The latter problem seems a much more
> likely cause to me, since I could only get the ENETUNREACH error by
> removing the default route from my workstation's routing tables.
> 
> I would therefor suggest that getting an ENETUNREACH should be grounds
> for completely aborting the log client startup process, rather than just
> trying the connection again later with the same address.
> 
> Completely aborting the client at this point gives the user the option
> of fixing the problem by changing EPICS_IOC_LOG_INET if necessary (or
> adding the appropriate route) and running iocLogInit() again.  Just
> retrying the same IP address again a few seconds/minutes later only
> solves the problem in scenario A above (and as I found, scenario A might
> not even be able to cause an ENETUNREACH).  Retrying does nothing for
> problem B; in that case the user would have to restart the IOC
> completely because we don't currently have any way of shutting down the
> log client in order to change its configuration parameters.
> 
> I am definitely distinguishing the ENETUNREACH case from a connection
> timeout problem where the log server might be down at the time the IOC
> starts - that's a case where we do want to keep the current behaviour
> since it's likely that the server will be restarted, and we'd want to
> connect to it automatically when it does.
> 
> - Andrew
> --
> There is considerable overlap between the intelligence of the smartest
> bears and the dumbest tourists -- Yosemite National Park Ranger


Navigate by Date:
Prev: Re: IocLogInit Andrew Johnson
Next: RE: ioc log client cpu consumption Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: IocLogInit Andrew Johnson
Next: RE: ioc log client cpu consumption Jeff Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  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 ·