EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  <19951996  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  Index 1994  <19951996  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 
<== Date ==> <== Thread ==>

Subject: Re: EPICS on the Alpha
From: [email protected]
Date: Fri, 10 Feb 95 12:40:58 -0600
>But can we really lose code which is there "for the sake of speed"? Full
>blooded conversion to ASCII data transfers would result in around 4x the amount
>of data bring transferred over the EtherNet at IOC startup. No problem for 
>small sites, but what about APS and CEBAF???

The byte counts have been shown to be considerably less... believe
it or not.  (It all depends on how you represent the data and so on.)
Last time I checked, we at APS, we are doing all our new work in ASCII
and moving our older stuff to it.  Here is some repost of a note I sent
out a year ago on the subject:

>As promised at the LANL Epics 'family' meeting in March... here are
>some test figures/times of what it takes to load the verbose ascii .db
>files verses the binary .database files generated by dct and gdct.
>
>First lets look at the input files themselves:
>
>This is the binary DCT database file:
>-rw-rw-r--  1 jbk       1843338 Apr  5 10:00 bpm.database
>
>This is the DCT short form report:
>-rw-rw-r--  1 jbk       1167186 Apr  5 10:05 bpm.ascii
>
>This is the ascii database from gdct:
>-rw-rw-r--  1 jbk        451111 Apr  5 10:29 bpm.db
>
>Ascii with everything (ie. fields with values set to their defaults)
>-rw-rw-r--  1 jbk       2555391 Apr  5 11:23 bigbpm.db
>
>As you can see, the ascii database file is about 25% the size of the
>binary database file (note, however that the ascii database file does
>not include the 200,000 byte default.dctSdr information...)
>
>Ok, so here are the loading time figures:
>==============================================================
>tickGet
>value = 1012 = 0x3f4
>dbLoad "/home/phebos2/WINANS/tmp/evansbig/bpm.database"
>value = 0 = 0x0
>tickGet
>value = 2112 = 0x840
>==============================================================
>tickGet
>value = 1081 = 0x439
>dbLoad "../../default.dctsdr"
>value = 0 = 0x0
>tickGet
>value = 1413 = 0x585
>dbLoadRecords "/home/phebos2/WINANS/tmp/evansbig/bpm.db"
>Warning: No EPICS version information in db file
>value = 0 = 0x0
>tickGet
>value = 2465 = 0x9a1
>==============================================================
>2112-1012 = 1100   (clock time for the binary load)
>2465-1081 = 1384   (clock time for equal information from ascii load)
>1384/1100 = 1.2581818181  (25.8 increase in time for ascii version)
>
>For the record content information only:
>2465-1413 = 1052   (clock time for ascii load w/o default.dctsdr)
>1100/1052 = 1.0456273764 (4.5% DECREASE in time for ascii version)
>
>The percent increase in time when using the dbLoadRecords on the ascii
>database file is 25.8%.  These loads were done on an unmonitored
>ethernet within 15 minuites of eachother... I am assuming that the
>acitvity was consistant enough in that period to factor out of
>consideration.
>
>Please note that this IOC was operating with FTP (as opposed to NFS)
>when accessing the files, therefore there is about a 2-second overhead
>of each file-read.  Thus the NFS difference in load times would be
>noticably less.  And if it is safe to assume that vxWorks does nothing
>significantly different in terms of task scheduling under NFS, redoing
>the above test should skew things in favour of the ascii file loader.
>
>----
>
>Notice that the dbLoadRecords command (curently) requires a dbLoad to
>preceed it.  And that the time for it was included in the worst case
>calculations (it seemed fair to me.)
>
>OK, so for one single database that contains 2722 records (that are
>about 50% ai and 50% ao) we are taking about 25% longer to load them
>when using the ascii file transfer.  But when loading a database in
>components, you will load the default.dctsdr file once and then, just
>load the ascii files.  And since it is actually 4.5% faster to
>load the ascii part than compared to the binary equivelant... those
>implimentations that load their databases in components actually
>run FASTER if they have more than 6 parts to them... as is not uncommon
>for the APS.
>
>A non-quantitive observation of the situation would show the lack of a
>need to maintain the code that operates on the binary and old 'short
>form' report files.  As well as the elimination of the headache of
>having to keep them in sync (which has been a significant complaint
>from APS users.) In fact, those users that have found out about the
>availability of the dbLoadRecords command no longer use their binary
>databases.  They claim that converting their home-brewed database
>configuration file formats (ranging from C programs that generate
>short-form reports to PC based database tools and text editors) into
>the required binary databases, can take as much as 20 minuites when
>using DCT in batch mode... and as much as 4 minuites when converting
>them to the ascii .db format with the tools we wrote to assist in the
>migration from binary to ascii databases.
>
>I will provide the database ascii and/or binary files to anyone that is
>interested in rerunning this test for themselves.  (preferably someone
>that is using NFS?)


I have been strongly advocating the movement into total ASCII database
files and the removal/replacement of the SDR stuff.  WRT the SDR stuff
--  At a minimum, it should be represented in ASCII and have some of the
oddities, like recSup.ascii, devSup.ascii and drvSup.ascii removed
somehow.

I am (obviously) not advocating the conversion to/from ASCII of the data
transfers that occur over CA... although, I see no reason to forbid
it... and in fact, I think it is already somewhat supported in that you
can fetch things in the form of a string.


--John

Navigate by Date:
Prev: Re: EPICS on the Alpha 415
Next: Re: EPICS on the Alpha Bob Dalesio
Index: 1994  <19951996  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: EPICS on the Alpha 415
Next: Re: EPICS on the Alpha Bob Dalesio
Index: 1994  <19951996  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 
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 ·