Limited cross site bandwidth SRDF question

Thanks ksmith!

That makes sense. We did see the SRDF/A session drop and it was because the utilization of the cache was going through the roof. I think for the time being we will throttle the acp_disk copies until we have the extra bandwidth in place.

I understand that transmit idle is enabled on a per group basis and the default is 60 seconds, though this site has it set at 30.

I'd just like to clarify a few things as I think the discussion may not be going in entirely the right direction.

First off can you please confirm the Enginuity level... You listed it as 5778. I was under the impression that 5774 was still the latest released version (although we are still running 5773 on DMX3 arrays).

Next I'd like to discuss Transmit Idle a bit. Unless I'm missing the mark entirely, I don't think Transmit Idle will have any impact on the situation you are describing. Without Transmit Idle there is a setting called "Link Limbo" which defines how long a link outage the SRDF/A can sustain before dropping out of Async mode and partitioning the pairs. With Transmit Idle enabled, TI kicks in once Link Limbo is exceeded and uses cache to continue to track changes at the source end so that consistency and proper write order can be maintained until the link comes back online.Once the maximum cache is consumed in TI mode, groups start dropping based on priority and usage (busiest group drops first freeing up resources for other groups). If you also have Delta Set Extension (DSE) configured, then instead of dropping when the TI cache gets full things start getting migrated out to the DSE pool from cache. When the link comes back up things are moved back into cache as space frees up and cache feeds directly to SRDF/A to push changed tracks across the link. Everything should stay in async mode... which effectively means that your R2 devs will stay consistent instead of having to resynch first.

None of that has anything to do directly with situations where the link is up but is just "full". In situations where the hosts are generating more change on the source volumes than you can push across to the target array. In this case the changes will pile up in the Write Pending (WP) cache. At some point the WP cache threshold will be reached and the busiest RDF group will be dropped out of asynch mode to reallocate WP cache to the other groups. Sometimes this will also drop other groups, but it shouldn't drop them all. We have run into this in the past and ended up going through a series of upgrades to resolve the issue so that the mainframe group stopped dropping regularly due to high activity. As an amusing side note, the error indicating that a group was dropped due to WP cache thresholds being exceeded included the code "CACA10" in the alert. This lead to the obvious naming of these errors as "CACA 10" errors (pronounced with a hard "C") :-)

So, none of this really answers the root question. We are also experiencing something in one of our environments which prompted us to ask EMC how we could ensure that SRDF/A traffic is not losing priority to ACP_Disk traffic. The only answer we could get is to apply QOS settings. We are still waiting for the details on how to make the correct changes. They are waiting for more info from our mainframe storage group in order to determine the correct settings. I would strongly recommend you engage your local EMC Account Team or CE for advice.