EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  <19971998  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  Index 1994  1995  1996  <19971998  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 
<== Date ==> <== Thread ==>

Subject: Re: medm/dm performance comparison
From: Ken Evans <[email protected]>
To: [email protected]
Cc: [email protected]
Date: Fri, 5 Dec 1997 11:19:32 -0600
     First, I should state that I am not intimately familiar with DM
and EDD.  In addition, Deb Kersteins, who is responsible for DM, and I
are on friendly terms.  I have not heard her promote DM at the expense
of MEDM, nor do I want to promote MEDM at the expense of DM.  I,
however, on a number of occasions have heard others say that MEDM is
slower than MEDM.  This may well be the case, but I have not yet seen
concrete evidence that it is.  I do feel a need to support MEDM.

     When Deb was at Argonne early this year we did some testing out
of curiosity.  We used the currently available version of both
programs and a database consisting of 100 analog input process
variables which could be set to update from never to once every .1
sec.  This database was originally made by Marty Kraimer.  We had ADL
files showing these process variables as meters and as text updates,
along with the controls to change the update rate.  What we did was to
set the updates to .1 sec and try to bring up as many screens as
possible before the screens could not keep up.  We used the meters.

     The programs were running remotely on what I believe was a Sparc
20 at the time and were displaying on a Sparc 20.  The typical result
was that each program could handle about 4 such screens.  At one time
MEDM was handling 6 and at no time did MEDM handle fewer than DM.  The
problem with this test is that the remote workstation was possibly
being used by others at the time and we do not know what its load was.
(This is the reason I used the word "informal" in describing the
tests.)  It certainly was not scientific.  Another factor is that it
is not clear the process was limited by the programs or the IOC.  The
IOC printed messages about events lost and discard counts when the
limit was reached.  We did it enough, however, that my impression was
that the performance of the two programs was about the same, and there
was no evidence that MEDM was inferior.  I think Deb agreed.  We did
not have time to do more than this.

     The bottom line is that there was no supportable evidence of a
difference in performance.

     As to the data presented by Matt Bickley.  MEDM 2.1.2 is a very
old version of MEDM.  (The current one is 2.3.3.)  I know that Fred
Vong worked on performance improvements in the 2.2.x series.  This
does not seem to be a fair or useful comparison.  It is certainly not
comprehensive.  

     If the relative performance of the two programs is an issue, then
they should be properly benchmarked before making statements about the
performance.  This would include testing with a suite of screens
typical of controls system operation.  It should be done in controlled
conditions with representation from both parties.  And, as is always
the case with benchmarking, there will still be room to argue.

     The suite should include plots.  The reason I mention plots is
because in my experience it is plotting that is most significant in
degrading the performance of MEDM or its workstation.  Plotting a
waveform of, say, 1024 points is three orders of magnitude more work
than a text update, both in the channel access required and in the
work done by the program and the X server.  Plots, however, are
extremely useful and people want them.  We are able to operate MEDM
successfully with quite a few rapidly updating plots.  However, there
are some plots that are avoided until needed because of the impact.

     Finally, MEDM appears to be adequately fast.  I do not get
complaints from operations about the speed.  To the extent they
complain at all, it is usually for new features.  Our storage ring
workstation, for example, runs nearly 100 MEDM screens on 15 separate
workspaces, along with application programs, analysis tools such as
SDDS, and UNIX programs such as Framemaker (for logbooks).  It takes a
few minutes to start up, but that is done with scripts and
configuration files so that the operator can do something else in the
meantime.

    It is not a problem.

	-Ken



Navigate by Date:
Prev: Re: MEDM 2.3.3 Roland Mueller
Next: Correlation plots Rolf Keitel
Index: 1994  1995  1996  <19971998  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: medm/dm performance comparison Matt Bickley
Next: Correlation plots Rolf Keitel
Index: 1994  1995  1996  <19971998  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 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·