Experimental Physics and
Industrial Control System

[email protected] · Mon, 28 Nov 94 10:45:24 -0600

Howdy all,

I have been on vacation for a while and before then, I stalled on this
because I thought others might have some better numbers 'from the field.'
I guess not.

The deal with booting an IOC is that it takes some setup time for each
file that is opened by vxWorks.  This is easily measurable when booting
via FTP.  In fact it is about two seconds for each file that is opened.
At the moment that goes for each 'ld', 'dbload', and 'dbloadrecords'
command.  And it adds up pretty fast.

I have not seen the NFS boot time numbers, but I suspect that they
would be the same, minus two seconds for each file opened.  I have been
waiting for one of our NFS users to post some numbers.  Mine below are
for FTP.

The test IOC in my office typically boots in about 30 seconds with a
minimal database and loading iocCore, drvSup, devSup, and recSup
seperately.  And the database in two pieces a'la:

dbLoad "default.dctsdr"
dbLoadRecords "Db/sysmon.db"

Just for yucks, I did an ld -r on all the parts and it knocked off
about 10 seconds.  Go figure.

So I guess this all means that you can't expect to be booting any
better than 20 seconds when just using FTP. to load all the components.

If you are willing to go thru the trouble, you could ROM your vxWorks
and loose the stupid vxWorks logo.  That would shave off about another
5 seconds.  (Why didn't I kill that logo in my BSP hack????  Something
for next time I guess.)

Next you could convert from FTP to NFS to load the EPICS components (or
even ROM them as well.)  Using NFS would save you the two seconds-per
access overhead (about 6 of those 20 seconed in my fastest boot times.)

So then, a ROM'd vxWorks image using NFS and a minimal database with
all the standard APS drivers and stuff would probably boot in about 9
seconds.

FYI -- I did a couple of giant database load tests this spring.  The
intent was to compare the ASCII format with the binary format.  Perhaps
it will give you some thoughts about how much time to add to the
above numbers to account for your database loading.  Enclosed is a CC
of that note.

Merry Christmas,

--John

========================================================================
========================================================================
========================================================================
>From [email protected]  Tue Apr  5 15:09:28 1994
Subject: Ascii 'db' -vs- binary 'database' file loading times
From: [email protected]

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

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?)

--John

! John Winans                     Advanced Photon Source  (Controls)    !
! [email protected]       Argonne National Laboratory, Illinois !
!                                                                       !
!"The large print giveth, and the small print taketh away." - Tom Waits !

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System