Performance Evaluation of EPICS on PowerPC
J.Odagiri, A.Akiyama, N.Yamamoto and T.Katoh
KEK, High Energy Accelerator Research Organization
Oho 1 - 1, Tsukuba, Ibaraki, JAPAN 305
Abstract

Table I

Summary of tested boards and software
A portion of software components of the Experimental
Physics and Industrial Control System (EPICS)[1] has been
ported to a VME single board computer based on a PowerPC
microprocessor. We have studied 1) the performance of adatabase scanning, 2) the Channel Access performance and3) interrupt latency on the PowerPC based CPU board.
The CPU load of the VME single board computer arising from the database scanning was measured using thestandard benchmark database developed by APS/ANL. The
transaction process time required for putting and getting avalue through Channel Access was studied as a performanceindicator of Channel Access. Interrupt latency was measured to study overall responsiveness to an external event
in EPICS on the PowerPC based board. The results of measurements were compared with the results on a 68040 based
CPU board.

Manuf.
CPU Type
Clock RateRAM
L2 Cache
VxWorks Ver.

PowerCore-6604
Force
PowerPC 604e
200 MHz16 MB
512 KB
5.3(Beta)

SYS68K/CPU-40
ForceMC68040
25 MHz
16 MB
5.2

2 Performance of EPICS software
2.1 EPICS software organization
EPICS software components running on an IOC[3] consists
mainly of: Run time database and associated routines to support

1 Introduction
In 1995, EPICS was adopted as a software platform for theKEKB accelerator control system[2]. In a control system
based on EPICS, high level applications do not access directly to physical devices but each device is controlled ormonitored through a run time database on a intelligent Input/Output Controller (IOC)[3] distributed around the system. Therefore, the performance of the IOC affects the overall performance of the system.
Nowadays, VME single board computers based on a highperformance CPU are available. The VxWorks real-timekernel[4, 5] required as a platform for EPICS is supported
on many of these boards. For better performances and continuity for the future, it is necessary to examine the possibility
to adopt such kind of high-performance boards.
We chose a PowerPC based model as one of the highperformance boards and studied performances of EPICS onthe architecture. EPICS version 3.12 was used for this evaluation. EPICS performances on a 68040 based board, which
is being used for the application developments of our system,
were also measured to compare the results.
Table I summarizes basic specifications of the boads andthe versions of VxWorks used for the evaluation.
In the following section, we will discuss the performancesof the database scanning and Channel Access from a hostcomputer. Interrupt latency is discussed in section 3.

dynamic activity of the database such as Scanners,Monitors, etc.
 Channel Access Server through which the IOCs communicate with each other and with a high-level workstation over the network in a media independent manner Three layers of routines called record support, device
support and driver support which allow the IOC to access physical devices
Figure 1 shows an illustration of the EPICS software components running on the IOC.
CA Server
CA UDPCA TCP

Task/ChDB AccessRuntime Database
DB lib/Record Support
Device Support
Device Driver

Scanner
EventSequencer

Hardware Interface

Fig. 1 Architecture of software running on the IOC in EPICS
In this paper, attention will be paid mainly to performances of software components commonly required for running EPICS, not depending on types of hardware interfaces.
Performances of physical device access will not be discussed.

To evaluate performances of software components running on the IOC, the following were measured: The CPU load arising from a scanning of the standard
benchmark database Transaction time required for putting and getting avalue to/from the IOC through Channel Access.
2.2 Database scanning performance
A standard benchmark database was developped byANL/APS [6]. The structure of the database is shown inFigure 2.
MainfanoutSubfanoutcalcaiaiai

calc

calc
Subfanout

Table IICPU load arising from the scanning of the benchmark
database

1.0 second
0.5 second
0.2 second
0.1 second

PowerCore-6604
0.60 %
1.2 %
3.0 %
6.1 %

SYS68K/CPU-40
5.8 %
12 %
27 %
56 %

The transaction time was measured for ca search, ca put,ca get, and for alternative execution of ca put and ca get. Table III summarizes the transaction time measured for those
processes. The CPU load of the IOC and network traffic
during the transaction were also measured (Table IV). Ifwe take 1/(Transaction time * CPU load) as an index of
the performance, the performance of the PowerPC based
board is about ten times as high as that of the 68040 based
board. This result is consistent with the previous result of
the database scanning.
Table III

Fig. 2 Structure of the benchmark database (The arrows indicate process links of EPICS database records)
A main fan-out record is processed by a periodic scanningmechanism. The main fan-out record processes two sub-fanout records three times per each scanning. Then, each subfan-out record processes five calculation records. Finally,each calculation record processes a chain of nine linked analog input records. About three hundred record processes takeplace in total by a scanning of the database. The I/O fields of
all records are software links so that any access to physicaldevices does not occur by the record processing.
During the measurement, all of the calculation records
and analog input records were being monitored by
MEDM[1], a GUI tool running on a workstation, through
Channel Access. This monitoring increased the CPU load
arising from the record processing and caused another CPU
load as a result of communication with MEDM.
The CPU load was measured for scanning periods of 1.0,0.5, 0.2, 0.1 second. VxWorks spy function[4, 5] was used
to measure the CPU load. The result of measurements isshown in Table II. The PowerPC based board shows the CPU
performance about ten times as high as that of the 68040
based board taking an inverse of the CPU load as an indexof the performance.
2.3 Channel access performance
The main routines of Channel Access[7] are:
 ca search used to establish and maintain a virtual circuit between a client and a server
 ca put used to write a value to a channel
 ca get used to read a value from a channel

Transaction time required for Channel Accessca searchca putca getca put&ca get

PowerCore-6604
953 micro-sec.
23 micro-sec.
58 micro-sec.
76 micro-sec.

SYS68K/CPU-40
1189 micro-sec.
109 micro-sec.
118 micro-sec.
246 micro-sec.

Table IV

CPU load and network traffic (in the form of a ratio to10MBit/sec) during the transaction

ca searchca putca getca put&ca get

PowerCore-6604
CPU Network
9%
17 %52 %
75 %
18 %
50 %
30 %
60 %

SYS68K/CPU-40CPUNetwork
68 %
20 %
100 %
18 %
82 %
25 %
88 %
20 %

3 Interrupt latency
Responsiveness to an interrupt from an external source is another important issue for real-time systems. We measured interrupt latency at two levels, i.e. at hardware/OS (VxWorks)
level and EPICS application level (post event)[3].
3.1 Latency at hardware/OS level
An Interrupt Request (IRQ) signal on the VME backplane
was driven through an I/O board. An instruction whichcauses access to a data register on the I/O board was executed at the entrance of the Interrupt Service Routine (ISR)
for the I/O board. The Data Acknowledge (DTACK) signals
associated with: reading out the interrupt vector from the interrupt vector register on the I/O board
 access to the data register on the I/O board caused by
the instruction in the ISR
were observed using an oscilloscope. Fig. 3.1 shows theobserved signals for the PowerPC based board. The first
DTACK signal corresponds to reading out of the interruptvector and the second corresponds to access to the data register.
The time between the rising edge of the IRQ signal andthat of each DTACK signal was measured as the latency. Theresult is shown in Table V.

processed. Then, an EPICS post event call which processes
those two records was issued at the entrance of the ISR. The
DTACK signal associated with each record processing wasobserved. Table VI shows the latency of those two record
processes. If we subtract the time required to start the processing of the ISR from the values listed in the upper row ofTable VI, the result also indicates that the CPU performanceof the PowerPC based board is about ten times as high asthat of the 68040 based board.
Table VI

Latency at EPICS post event processing

firstsecond

PowerCore-6604
12.5 micro-sec.
19.5 micro-sec.

SYS68K/CPU-40
73 micro-sec.
122 micro-sec.

4 Conclusion

Fig. 3 The IRQ and DTACK signals on the VME backplane ( Upper: IRQ signal, Lower: DTACK signals, 1 microsec./div. time scale)
Table VInterrupt latency at hardware/OS levels

Vector
ISR

PowerCore-6604
1.0 micro-sec.
6.0 micro-sec.

SYS68K/CPU-40
2.1 micro-sec.
5.4 micro-sec.

It should be noted that the CPU does not yet know about
the interrupt when the first DTACK signal goes back. TheVMEbus interface chip on the CPU board returned thefirst DTACK signal before the CPU accepted the interrupt.
Therefore, the time between the first and second DTACK
signals includes some communication latency in the CPU
board in addition to the time required for switching the context to the ISR.
3.2 Latency at EPICS post event processing
Two records were loaded to the IOC in advance. Each record
causes access to a data register on the I/O board when it is

The EPICS software components running on the IOC wereported onto the PowerPC based VME single board computer
without any significant problem. The measurements on theperformances of the database scanning and Channel Accessshowed about ten times CPU performance improvement overthe 68040 based board.
As to the interrupt latency, the PowerPC based board required slightly longer time to switch a context to the ISR
compared to the 68040 based board. However, as expected,
it showed better performance at the EPICS post event processing where the software overhead was dominant. Theseresults encouraged us to adopt PowerPC based CPU boards
for the KEKB accelerator control system.
Acknowledgements
We would like to thank Mr. M.Hakuta (LOGIC HOUSEcorporation) for his offering the PowerPC based CPU boards
for the evaluation.
References
[1]

[2]
[3]
[4]
[5]
[6]
[7]

L.R.Dalesio et al., “EPICS Architecture”, in Proceedings of ICALEPCS’91, KEK, Tsukuba, Japan, 1991,
pp. 278-282.
T.Katoh et al., “Present Status of the KEKB ControlSystem”, in these proceedings.
J.B.Anderson and M.R.Kraimer, “EPICS Input/OutputController(IOC) Application Developer’s Guide”.
“VxWorks Programmer’s Guide 5.3”, WindRiver Systems, Inc..
“VxWorks Reference Manual 5.3”, WindRiver Systems, Inc..
M.Kraimer, private communication.
J.O.Hill, “EPICS R3.12 Channel Access Reference
Manual”.