Experimental Physics and Industrial Control System

G'day Jack, et al.

My opinions mostly follow, but you did ask....

The figures Andrew showed probably came from me - or at least I supplied some of the input data for them. 
Side note: I joined the APS two years ago, after setting up the Australian Light Source or Synchrotron Light Source Australia (SLSA) as I think they now wish to be known as.
(Back in my day we called it the ASP - P for project). So I went from ASP=>APS! Anyway, at the SLSA (or AS or ASP) we were lucky in that we were able to control very tightly the relatively small number of IOC and never had to make the R3.13 to 3.14 transition with operational equipment. It can be a major upgrade.

One of the issues is that a fairly large installed base at the APS with around 345 IOC's is that keeping them at all the same revision is hard - especially if you are migrating from a very stable version. The incentive to upgrade is not immediate. Particularly as the hardware requirements for EPICS 3.14 are greater than 3.13 in some circumstances.

So, after I arrived I discovered that only a fairly small percentage of IOCs had been converted. The motivation to convert and the difficulty in doing so, and the number of changes sensible to make on a machine that is only allowed a few regular planned maintenance outages per year (and a lot of other things are also upgraded during that time)  means that with a relatively small staff count per IOC, only so much progress can be made.

Note the less, my motivation for a uniform EPICS base is as follows:

1/ Support for old versions of EPICS is harder. however, when I pressed Andrew about this, he said he could still support 3.13, but actually in truth didn't recall 
much need to support it. It's easier for other (us mortals) staff if everything is as uniform as possible too. This works for both Operating systems and EPICS base versions.
2/ The older hardware is getting very old. Spares are impossible to get. Replacing it with new hardware forces an EPICS upgrade (and possibly a VxWorks upgrade) at the same time. 
If you are recovering from a failure and have a beam downtime pressures on you, the last thing you want is to make a large number of simultaneous changes with software and hardware. This can be the difference, say between a one hour down time and one of a few days or worse. Scary scenario if you need to make 99% or greater availability.
3/ New features . If you need them in existing equipment. Mostly we don't. Only sometimes we do
4/ Bug fixes. If they apply to existing equipment. Mostly they don't.

I'm very pleased to say that over the last two years, we've made quite significant progress  - there only about 70 IOC's on the accelerator to go now (as you noticed), and most of them left are dependent on hardware upgrades, which take real dollars out of a limited budget and so that will be the limiting factor in the end. The hardest IOCs to convert have been those involved with real time feedback and timing, but there are some gotcha's in the other subsytems as well. One other factor is we have been able to convert to a number of SoftIOCs too - which messes with percentages.. 

Nonetheless, when we need the latest version of EPICS, we will use it - we are putting new IOCs in still - even nearly 20 years after becoming operational. And on the accelerator, the IOC's will always lag a little (or a lot) behind the lead for most of our IOCs - and I guess that's just fine.
 
hope that helps.

Richard


>
>You will hear from the accelerator folks on the details.  The overview is that some systems remain on legacy versions of EPICS base because they depend on reliable, yet legacy hardware.  >With the impressive uptime that the accelerator is run and the number of IOCs in deployment, one can appreciate that a conservative approach to upgrades has been adopted.
>
>The X-ray beam lines (who are direct beneficiaries of the efforts of the EPICS core team) that run EPICS (200 VxWorks IOCs, ca. 100 Linux IOCs, perhaps a few RTEMS IOCs) are all on 3.14 >versions.  It is much easier to apply upgrades at beam lines since they each independently and can be upgraded on an individual basis.
>
>Pete
>
>>On 11/21/2012 2:54 PM, Jack Smith wrote:
>>
>>    Hi Andrew,
>>
>>    Thanks for pointing out the new features in the Base 3.15.
>>
>>    I'm very surprised by the chart "Accelerator IOC EPICS Versions" in
>>    your presentation: ~60% IOCs were using aged version 3.13 in March,
>>    2011 and 25% in Sept. 2012. I always think that APS is the pioneer in
>>    the EPICS base. But after seeing this chart, I think that APS is
>>    pioneering in the base development rather than the deployment. Could
>>    anyone share your experience and opinion why it is so difficult to
>>    upgrade the legacy to the up-to-date?
>>
>>    Thanks,
>>
>>    Jack

Navigate by Date:

Prev: Re: caRepeater object code not cross-compiled in R3.14.12.2 Rod Nussbaumer

Next: Error building asyn4-20 on CentOS 6.3 Andre Charbonneau

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: 3.14 v.s. 3.15 vs. v4 Pete Jemian

Next: How to debug an IOC running on MSWindows using windbg Paul.gibbons

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