Vince,

Deltamark is used to count the number of tracks that will change over a given period. This can be useful for determining the daily change rate for say re-syncing BCV's or give you an idea how large your Save pool needs to be for Snapshots..

What deltamark does not show is how many times a device is written to per second, and it also doesn't count re-writes to the same track, so for srdf/s planning purposes, it's not very good at all as sync rdf has to deal with all of these write I/O's.

I would recommend that you look at the following:

1. write IO's per second to determine if your devices are doing more I/O's than is sustainable when SRDF is enabled. The additional overheads of SRDF and the propogation delay will effect the maximum writes per second achievable for a single hyper. If you have SRDF already going, look at the sampled average rdf write time to understand how long that overhead is. (you may need emc139254 to get this info) (eg: if the rdf write time is 2ms, then a device can do max 500 IO's/sec (1000msec/2ms) ) If you have devices doing more than 500 writes per second, then you are definately going to see an impact, and you will need to spread that workload across more devices... Also get a total peak write I/O's per sec for all of your devices so you can work out how many RA's you will need (see below)

2. To work out the bandwidth requirements, its close enough to simply sum the KB written for all of the volumes you plan to turn into R1's.

3. Finally you need to determine the # of RA's (SRDF processors) required - this will be based on your peak write IOPS and throughput numbers. There are too many variables to discuss here - you are best to contact your EMC rep once you have the figures and they can assist with this step.

Regards,
Glen.