Experimental Physics and
Industrial Control System

"Brett M. Kettering" <[email protected]> · Fri, 22 Aug 1997 11:54:53 -0700

Hi all,

We are not users of EPICS, but I know you all have a great deal of
experience with VxWorks systems.  Included in this message are some
excerpts from a document that I am putting together that describes how we
will boot our system from the ground up.  Can you all please give me the
benefit of your experiences with bootpd, tftpd, inetd, rarpd, dhcpd, etc.
to accomplish this task?

1. The units containing the disk drives must come on-line first. No
computer can boot without the disks on which reside the operating systems
and applications. Network bridges, switches, routers, etc. may also boot
concurrent to the disk drives becoming ready as they do not require the use
of the disk nor the computers that own the disk drives.

2. The two principal file server computers are the owners of all the disk
drives and therefore must be the first computers to boot. They may also
boot concurrently.

3. Though it is possible that the FEPs (Front-End Processor) and the
workstation computers may boot concurrently, it may be desirable to use the
workstations to distribute the load of booting the FEPs. In reality the
bottleneck will likely be access to the disks on which the FEPs? boot
parameters, operating systems (most of which will be VxWorks), and
applications reside. Some consideration to the distribution of these files
over several disks, accessible by several disk I/O channels, may be
desirable. This may seem more practical if the FEP applications are linked
with the VxWorks kernel. Another thing to keep in mind is that there are
only 13 types of FEP applications (not that many unique application/kernel
images) and approximately 260 FEPs (120 of which are of one type). This
could speed us up somewhat, though 120 of the same image will become the
bottleneck if it resides in one location on one disk. So, at this point the
15 workstation computers will boot as diskless clients of the two file
server computers. How does the time to boot all diskless clients calculate,
based on the number of diskless clients, as the number of concurrently
booting diskless clients increases; linearly, exponentially?? Concurrent to
the booting of the workstation computers the file server computers may
start running the Central System Manager and Configuration Server
applications. All the Oracle database server processes and general
information and service server processes may also be started on the file
server computers.

4. After the workstation computers are all booted the FEPs may retrieve
their boot parameters from the bootpd (apparently rarpd on Solaris) daemon.
I am currently reading up on this daemon to find out if it handles the boot
parameter requests synchronously or asynchronously, how much time it takes
to handle a request, and if it handles requests asynchronously how many
concurrent requests it can reasonably handle??

5. As each FEP receives its boot parameters and sufficient workstation
computer or file server resources are available the FEP may download its
operating system via TFTP. This daemon I know operates asynchronously. The
question to answer is how many concurrent requests can be handled and how
long do they take to process?? This begs the question of how large the
FEP?s operating system is??

6. Assuming the FEPs? application images are separate from the operating
system the FEPs may now download their application images and start them
running. Should this be done via the startup script mechanism in VxWorks
using rsh?? Or, can the application images be downloaded via TFTP and then
start running?? What about the FEPs that use the Solaris operating system??
Again, we need to know how large the application images are and how many
can reasonably be concurrently serviced by the boot server computers??

Thanks,
Brett

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System