This website is no longer maintained. Its content may be obsolete. Please visit http://home.cern for current CERN information.
Comments received after the meeting: from Nikolai (size & documentation), from Niall (word document - wide versus narrow interfaces).
Replies to comments: Niall's Kris's
Meeting held on Thursday 07-02-2002 - reported by Mike Lamont
Present : Andy Butterworth, Mike Lamont, Mark Tyrrell, Jean-Jacques Gras, Alastair Bland, Kris Kostro, Quentin King, Michel Jonker, Stephen Page, Marc Vanden Eynden, Franck Di Maio, Steen Jensen, Vito Baggiolini, Niall Stapley, Nikolai Trofimov.
Kris presented a summary of the present state of the CMW project. His slides here.
Noted:
Quentin presented vision and requirements for LHC power converter control. He also presented his reasons for withdrawing from the collaboration with the CMW project:
Quentin also outlined his idea to use a socket based scheme until a reliable alternative was available, his deadline being the need to have a reliable prototype in place for the next phase of string 2. Question: of stated middleware requirements which ones need to be met to meet this requirement.
Supplementary discussion on the use of strings...
Towards the end of the discussion Quentin proposed that he carries on developing the gateway architecture using sockets in the interim. If in 6 month the middleware was in good enough shape then he would reconsider rejoining the collaborative effort. This was felt to be a shame: the technical problems should be resolved with PS allowing Nikoli to dedicate himself to the problems.
Jean-Jacques outlined the situation in BI. BISCOTO provides a number of alternative interfaces. SL-EQUIP, TCP-IP, SPS2001, CMW. The CMW implementation had proved more difficult (actions not an obvious set/get), however BI have made the effort to become Device/Property compliant and are nearly ready to test. Interface to filters for customised set/get is mandatory but OK for them
Issues for BI:
5 to 6 instruments based on this for the startup.
One server required per front-end even if more that one instrumentation type on front-end. Discussion about size... see below.
Frank summarised the situation in the PS. Since the end of 1999 they have a Java Interface and about 10 Java applications for AD operations running. At the end of 2001, 2 weeks before the end of operations for the year, all AD front-ends switched to the CMW framework. Extensive tests and debugging was performed. The AD was then operated with the new system. No problems in RDA although a rewrite of the framework was necessary.
2 major problems:
All known bugs and problems with robustness fixed, performance has been good (1000 sends in 200 ms including access to SHM.) Will start-up this year with all AD applications using CMW. Extensions planned.
CMW needs 5 Mb on the DSCs, memory extensions were/are necessary. Old DSCs which cannot be upgraded will shift to a 3 tiered system.
Clearly Corba exacts an overhead. Lot of effort put into diagnostics and monitoring. Strong team needed for technical troubleshooting and support.
Vito briefly summarised the situation in EA. The front-ends in EA are PC386 which precludes the use of CMW. They use SL-Equip via C to Java gateway interface. New developments are based on VME front-ends and Biscoto, and the Cesar project will use CMW as soon as it has been connected to Biscoto. As for JMS, they already use it for software timing distribution and plan to use it for other purposes (e.g. Teletext Pages) in future.
He feels that the lack of strong technical support in SL compared with that the PS has enjoyed is one reason for ongoing problems in SL.
Michel Jonker made two points regarding the SPS2001 approach.
Steven Page had tried to use an early version of the SPS2001 settings contract framework. Settings containers are NOT based on integers.
Contracts on CMW: should be able to map contracts to properties. Michel has
provide stripped down version but he and Kris need to sit down and work out
the details of how it might be done.
DIM has been chosen by two of the LHC experiments as a temporary solution. It has no OO support, although there is a good Java interface (minimal when CMW performed their evaluation). Short discussion on relative merits (handling of disconnections, standards, extensibility, type checking etc.)
It ain't how big it is, it's what you do with it. However a 9 Mb binary is verging on the silly.
Distinguish between binary size and the load on resident memory at runtime which is of the order of 2 Mb.
Embedded Corba - Basic OrbacusE, simple as it gets, comes in at 100 Kb. Basic unembedded Corba, IDL interface comes in at 300 Kb.
Concerns:
Could reduce memory requirements to less than 1 Mb using embedded version. Not thought, until now, to be a priority.
It is clear that CMW is moving towards becoming a credible solution as evidenced by its use by the PS to run the AD machine. However, the attempted use, for tests and by prototypes, within SL have revealed shortcomings:
There are also wider questions as to it appropriateness. In attempting to meet the many requirements the different users have of a middleware has it become unwieldy and thus instrincally difficult to maintain and use? "What you need is Notepad and you're providing word" to quote Niall.
A lightweight alternative does exist: DIM (with or without contracts). However, CMW were charged with evaluating and selecting a product. For good reasons they have chosen a commercial product widely used in industry and in the accelerator sector. It is heavy, but this is not a reason to damn it in itself c.f. Oracle.
Development within SL should continue to attempt to use CMW, with the proviso that the most important of the issues raised above be addressed with some urgency.
Expertise must be engaged.
Need to prioritize future enhancements, fixes, and improvements.
Prototype CMW/contracts needs to be developed.
A review, performed by persons external to the project, is required to verify provided functionality against requirements and to perform a critcal code review.