Experimental Physics and
Industrial Control System

"Mark Rivers" <[email protected]> · Mon, 26 Jan 2009 10:28:56 -0600

I have a very contemporary Windows system and it takes many minutes to
rebuild the IOC with total CPU saturation of one core.  It depends
entirely on how many source files must be recompiled (e.g. when a single
header file is changed) and how many libraries must be linked into the
resulting executable.

-----Original Message-----
From: Jeff Hill [mailto:[email protected]] 
Sent: Monday, January 26, 2009 10:25 AM
To: 'Andrew Johnson'
Cc: Mark Rivers; 'epics'
Subject: RE: Very slow reconnection to medm after IOC reboot

> Unfortunately on Windows this is not possible; installing a new
version of
> a .DLL or .EXE is not permitted by the OS until all programs using it
have
> quit, thus one has to stop the IOC before the rebuild can be started.

On any contemporary windows system it takes less than 30 seconds to
rebuild
the IOC - so this would work also?

O stop IOC
O rebuild IOC
O start IOC

I don't doubt that optimizations can be installed, but my perspective is
that this should not impact the stability of R3.14.

> -----Original Message-----
> From: Andrew Johnson [mailto:[email protected]]
> Sent: Monday, January 26, 2009 8:57 AM
> To: Jeff Hill
> Cc: 'Mark Rivers'; 'epics'
> Subject: Re: Very slow reconnection to medm after IOC reboot
> 
> On Friday 23 January 2009 16:40:22 Jeff Hill wrote:
> > But perhaps this would work just as well (with very fast reconnect
times)
> >
> > O rebuild the application
> > O reboot the IOC
> 
> Unfortunately on Windows this is not possible; installing a new
version of
> a .DLL or .EXE is not permitted by the OS until all programs using it
have
> quit, thus one has to stop the IOC before the rebuild can be started.
> 
> > Nevertheless, if by chance one ends up with the first scenario,
> restarting
> > the MEDM screen isn't, from my perspective, exactly heavy lifting -
> > considering that we are presumably waiting at the edge of the seat
for
> the
> > channel's to reconnect. Synchronization might be the primary
aggravation,
> > but perhaps it will even be successful the first try if one waits
> > approximately long enough for the IOC to finish rebooting before
> restarting
> > the medm screen.
> 
> For the moment that does appear to be Mark's only alternative to
waiting
> the 4
> minutes, but this is not an acceptable long-term solution (and
contrary to
> what you say below, this needs to be fixed in R3.14 since it got
broken in
> R3.14).  I'd like to have a discussion (on core-talk or at the
codeathon)
> about other reconnection algorithms that could be used to fix this
while
> still protecting the network from the UDP storms that we used to get.
> 
> > I am busy with other projects at the moment, but perhaps you might
> consider
> > creating a mantis entry (we want to minimize changes to R3.14 so
this
> would
> > be against R3.15) describing the problem (and including a copy of
this
> mail
> > exchange), and perhaps some improvements can be made (within the
> > constraints of reliable operation of course).
> 
> I have filed Mantis bug #330 which refers to this tech-talk discussion
> thread
> for the details.
> 
> - Andrew
> --
> The best FOSS code is written to be read by other humans -- Harold
Welte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System