SPXTAPE Performance
Last updated 18 January 1999
The following is an excerpt from VM/ESA Release 2.2 Performance
Report (GC24-5673-01).
The SPXTAPE CP command is provided in VM/ESA Release 2.2 as a
high-performance alternative to the SPTAPE command. (Note that SPTAPE
is no longer supported.) These commands
are primarily used to dump and load spool files to/from tape. See
for a discussion of the techniques SPXTAPE uses
to achieve this improved performance.
A set of measurements was collected in order to assess the
performance of the SPXTAPE command. Most of these measurements were
done in a dedicated environment (no other system activity) and were
used to compare SPXTAPE to the SPTAPE command. The primary metric
was the elapsed time required to process a given number of
spool files.
One of the SPXTAPE DUMP cases was then repeated while the
system was running the FS8F CMS-intensive workload at 90%
processor utilization in order to observe the interactions between
SPXTAPE and concurrent system activity.
Workload: SPTAPE or SPXTAPE:
Hardware Configuration:
Processor model: 9121-742
Storage:
Real: 1024MB
Expanded: 1024MB
Tapes: 3490 (1, 2, or 4 used)
DASD:
Type of Control Number - Number of Volumes -
DASD Unit of Paths PAGE SPOOL TDSK User Server System
3390-2 3990-2 4 6 4 R 2 R
Note: R or W next to the DASD counts means basic cache enabled or DASD
fast write (and basic cache) enabled, respectively.
Software Configuration
Virtual Machine
Machine Number Type Size/Mode SHARE RESERVED Other Options
OPERATOR 1 SPXTAPE 24MB/XA 100
SMART 1 RTM 16MB/370 3% 500 QUICKDSP ON
Note: RTM was only active for certain measurements (see results).
Additional Information:
Spool files dumped/loaded: 34,000
Spool pages dumped/loaded: 353,000
Average pages per file: 10.4
Measurement Discussion:
For the SPTAPE DUMP and SPXTAPE DUMP measurements, the system was
prepared in advance by creating (approximately) 34,000 reader files
on four 3390 spool volumes. The reader files ranged in size from
100 to 600,000 80-byte records and occupied, on average, 10.4 spool
pages. The distribution of sizes was chosen so as to approximate
the distribution of spool file sizes that was observed on a local
CMS-intensive production system. The reader files were created
concurrently by 8000 autologged users. SPTAPE or SPXTAPE were
then used to dump these spool files to one or more 3490 tape drives.
For the SPTAPE and SPXTAPE LOAD measurements, the spool files were
first purged from these same four spool volumes. The SPTAPE LOAD
measurement was done by loading the tapes that had been created
by SPTAPE DUMP. The SPXTAPE LOAD measurement was done by loading the
tapes that had been created by the 1-tape SPXTAPE DUMP.
All required tape cartridges were preloaded into the 3490 cartridge
stacker so that tape change time was as short and consistent as
possible. Tape change time was observed to require about 1 minute and
was mainly due to the time required to rewind the tape.
For each measurement, the timestamps provided in the summary log file
created by SPTAPE or SPXTAPE were used to calculate the elapsed
time. Additional timestamps in the summary log file were used to
calculate the amount of time during which a tape drive was idle because
a tape cartridge was being changed (Tape Change Time) and the amount
of time this caused the system to be idle (System Idle Time).
RTM VM/ESA was active for some of the measurements. In those
cases, the results table (Table 1) also includes
processor time and processor utilization data.
Table 1. SPTAPE and SPXTAPE results -- dedicated 9121-742
Command
Function
Tape Drives
|
SPTAPE
DUMP
1
|
SPXTAPE
DUMP
1
|
SPXTAPE
DUMP
2
|
SPXTAPE
DUMP
4
|
SPTAPE
LOAD
1
|
SPXTAPE
LOAD
1
|
Elapsed Time
Elapsed Time (sec)
Elapsed Time Ratio
Rate Ratio
|
3:24:39
12279
1.000
1.00
|
22:42
1362
0.111
9.02
|
19:27
1167
0.095
10.52
|
18:55
1135
0.092
10.82
|
2:09:32
7772
1.000
1.00
|
1:07:42
4062
0.52
1.91
|
Tape Change Time (sec)
System Idle Time (sec)
Overlapped Tape Change Time (sec)
Percentage Overlap
|
653
653
0
0
|
371
230
141
38
|
309
0
309
100
|
247
0
247
100
|
671
671
0
0
|
371
0
371
100
|
Tapes
Percentage Reduction
|
12
|
7
42
|
7
42
|
8
33
|
12
|
7
42
|
Processor time (sec)
Processor utilization (%)1
|
|
|
79
1.7
|
|
|
902
5.6
|
Elapsed Time Ratio was calculated as SPXTAPE
Elapsed Time divided by SPTAPE Elapsed Time.
Rate Ratio was calculated as the reciprocal of
Elapsed Time Ratio. Rate Ratio represents
how many times faster SPXTAPE ran relative to the corresponding
SPTAPE measurement.
Overlapped Tape Change Time was calculated by
subtracting System Idle Time from Tape Change
Time. Percentage Overlap was calculated as 100% *
Overlapped Tape Change Time divided by Tape Change
Time. This represents the percentage of time that changing
tape cartridges was overlapped with other processing.
As shown in the above table, SPXTAPE was 9.0 to 10.8 times
faster than SPTAPE for dumping spool files for the measured cases.
The 2-tape and 4-tape cases were somewhat better than the 1-tape case
because tape changes were completely overlapped with other processing.
SPXTAPE was 1.9 times faster than SPTAPE for loading spool files
for the measured 1-tape case.
The number of spool volumes is an important variable in
determining how long it will take SPXTAPE to DUMP or LOAD a set of
spool files. The more spool volumes there are, the faster SPXTAPE
will tend to run because the spool I/Os are done in parallel across a
larger number of devices. By contrast, SPTAPE only works with one
spool volume at a time. Consequently, the performance relationship
between SPTAPE and SPXTAPE will depend, among other things, upon
the number of spool volumes. Four spool volumes were used in this
test and resulted in roughly a 10:1 elapsed time improvement for
dumping spool files. Cases where fewer spool volumes are involved
will tend to see a smaller improvement than this, while cases with
more spool volumes will tend to see a larger improvement.
SPXTAPE DUMP time is also sensitive to the distribution of spool
file blocks across the spool volumes. This was illustrated by the
results obtained from a 2-tape SPXTAPE DUMP of the same 34,000 files
that had been built onto the 4 spool volumes by restoring from the
SPTAPE dump tapes. Even though the files were the same, the elapsed
time was 70% longer than the 1167 seconds shown in Table 1 because those files were less favorably distributed
across the spool volumes.
One of the ways in which SPXTAPE provides better performance
relative to SPTAPE is by reducing the amount of time it is idle
waiting for a tape to be changed. This is shown by the reduction in
System Idle Time in the results table. Three factors
contribute to this improvement:
- SPXTAPE uses fewer tapes, resulting in fewer tape changes.
- Unlike SPTAPE, SPXTAPE supports the use of multiple tape
drives. When two or more tape drives are made available, SPXTAPE
is able to continue processing with another tape while one tape is
being changed.
- SPXTAPE uses available real memory to buffer data. For example,
during a SPXTAPE DUMP to one tape drive, when that tape drive becomes
temporarily unavailable due to a tape cartridge change, SPXTAPE
continues to read spool files from DASD and stages them in real
storage. This buffering continues until there is no more available
real storage or the tape drive becomes ready again.
SPXTAPE looks at system paging indicators to determine how much
of the system's total real storage it can use. In these dedicated
measurements, SPXTAPE was able to use large amounts of real storage
for this buffering, resulting in substantial overlapping of processing
with tape changes. For the 1-tape DUMP, it was able to overlap 38% of
the tape change time. For the 1-tape LOAD, it overlapped all of the
tape change time. The degree of overlap would be much less, of course,
on systems with less real memory or in cases where there is
concurrent activity that has significant memory requirements.
The results show that SPXTAPE elapsed time was relatively
insensitive to the number of tape drives that were used. Elapsed
time decreased by 14% when going from 1 tape to 2 tapes. There was
very little further elapsed time reduction when going from 2 tapes
to 4 tapes. This is because, with only four spool volumes, the
limiting factor tended to be the time required to transfer the spool
files from/to DASD.
SPXTAPE DUMP and LOAD processing result in
low processor utilizations. Even though the I/O processing is heavily
overlapped, the SPXTAPE DUMP and LOAD functions are I/O-bound.
The SPXTAPE LOAD measurement was run with default options in effect.
SPXTAPE offers a NODUP option. If selected, SPXTAPE ensures that
each loaded spool file is not a duplicate of any spool file that
is already on the system. Use of this option can increase processing
requirements significantly because each incoming spool file must be
checked against all existing spool files.
SPTAPE writes a tape mark between each backed up spool file. The
smaller the files, the more tape space is taken up by these tape
marks. SPXTAPE writes the spool file data as one tape file
consisting of 32K blocks. This reduces the number of tape volumes
required to hold the spool files. The smaller the average spool
file size, the larger the reduction relative to SPTAPE. For the
measured environment, the average spool file was 10.4 pages and a 42%
reduction in tapes was observed (1-tape case).
One disadvantage of using multiple tape drives with SPXTAPE is
that it can increase the number of tapes required. For example, the
SPXTAPE DUMP to 1 tape drive required 7 tapes, while the SPXTAPE
DUMP to 4 tape drives required 8 tapes. Using "n" tape drives
means that there are "n" partially filled tapes when the dump
has completed. Because of this, it is better to use no more tape
drives than is necessary to keep DASD I/O as the limiting factor,
with a minimum of two tapes in order to get the tape change overlap
benefits. For the measured case, 2 tape drives was a good number.
For a case where there are far more spool volumes, using more than
two tape drives can be beneficial. The suggested rule-of-thumb is
one tape drive for every 4 to 6 spool volumes, with a minimum of
two.
SPXTAPE will tend to perform especially well relative to SPTAPE
when one or more of the following conditions apply:
- The spool files are spread across many spool volumes.
- Two tape drives are used (or more, if appropriate).
- Tape change times are long.
- The spool files are small.
A measurement was done to explore the degree to which SPXTAPE
DUMP can affect the response times of concurrent CMS interactive
work and the degree to which that activity can affect the elapsed
time required to complete the SPXTAPE DUMP function.
Workload: FS8F0R + SPXTAPE DUMP:
Hardware Configuration:
Processor model: 9121-742
Processors used: 4
Storage:
Real: 1024MB
Expanded: 1024MB
Tapes: 3480 (Monitor)
3490 (2 tapes, used by SPXTAPE)
DASD:
Type of Control Number - Number of Volumes -
DASD Unit of Paths PAGE SPOOL TDSK User Server System
3390-2 3990-3 4 6 7 7 32 R 2 R
3390-2 3990-2 4 16 6 6
Note: R or W next to the DASD counts means basic cache enabled or DASD
fast write (and basic cache) enabled, respectively.
Note: The spool files backed up by SPXTAPE were all contained on 4 of the
spool volumes behind a 3990-2 control unit.
Communications:
Lines per
Control Unit Number Control Unit Speed
3088 1 NA 4.5MB
Software Configuration
Driver: TPNS
Think time distribution: Bactrian
CMS block size: 4KB
Virtual Machines:
Virtual Machine
Machine Number Type Size/Mode SHARE RESERVED Other Options
OPERATOR 1 SPXTAPE 24MB/XA 100
SMART 1 RTM 16MB/370 3% 500 QUICKDSP ON
VSCSn 3 VSCS 64MB/XA 10000 1200 QUICKDSP ON
VTAMXA 1 VTAM/VSCS 64MB/XA 10000 550 QUICKDSP ON
WRITER 1 CP monitor 2MB/XA 100 QUICKDSP ON
Unnnn 5500 Users 3MB/XC 100
| 
