==============================================================================


RE: ADSM Performance with and without EOS Memory

I thought I share this bit of information with the group.  I am not
recommending using parity memory on PC Server 500 or 520 machines, but I might
keep some parity memory on the side if I every get into a bind.

The following full D drive restores were performed.  KBs recovered and GB/hour
reflect compressed data.  We usually assume a 2:1 compression ratio so raw
numbers are twice the value shown.


                                   SESSION
MEDIA                                   AVERAGE
                                  IDLE WAIT COMMUNICATION     WAIT
OBJECTS     KILOBYTES GIGABYTES  OBJECT   COMMUNICATION NODE
 START TIME STAMP DURATION TERM     TIME      WAIT TIME       TIME
RECOVERED    RECOVERED PER HOUR  SIZE (MB)    METHOD     TYPE

 24APR97:08:48:43 10:02:08 NORM    3:04:46     4:34:33     0:11:23
401280      4,608,368   0.466       0.011    Tcp/Ip     OS/2
 30APR97:10:50:35  5:51:42 NORM    1:20:12     2:30:30     0:04:45
401246      4,608,190   0.798       0.011    Tcp/Ip     OS/2


The first restore was done using a PC Server 520 with EOS memory as the ADSM
client.

The second restore was done on the PC Server 520 but with parity memory.

In both cases the same data was restored from the same ADSM/MVS server.  I
attribute the slight
difference in objects and KBs transferred to comm error
recovery/retransmission.  While the restores
were not done in a controlled environment, I believe the workloads were
comparable.  The numbers
really do reflect the overhead associated with error correction logic on the
EOS memory.  I saw
similar results between ECC and parity memory on the PC Server 500.  Other
machines with memory
error correction algorithms may have a similar overhead.

Most of the overhead is present in the file examination phase of the restore,
but also seems to
have an influence during the rest of the operation.