Global Mirror uses the gmmaxhostdelay  and gmlinktolerance  parameters to monitor Global Mirror protocol backlogs in the following ways: 

GLYPH<SM590000> Users set the gmmaxhostdelay  and gmlinktolerance  parameters to control how software responds to these delays. The gmmaxhostdelay  parameter is a value in milliseconds that can go up to 100. 

GLYPH<SM590000> Every 10 seconds, Global Mirror samples all of the Global Mirror writes and determines how much of a delay it added. If at least a third of these writes are greater than the gmmaxhostdelay  setting, that sample period is marked as bad . 

GLYPH<SM590000> Software keeps a running count of bad periods . Each time that a bad period occurs, this count goes up by one. Each time a good period occurs, this count goes down by 1, to a minimum value of 0. 

The gmlinktolerance  parameter is defined in seconds. Bad periods are assessed at intervals of 10 seconds. The maximum bad period count is the gmlinktolerance  parameter value that is divided by 10. For instance, with a gmlinktolerance  value of 300, the maximum bad period count is 30. When maximum bad period count is reached, a 1920 error is reported. 

Bad periods do not need to be consecutive, and the bad period count increments or decrements at intervals of 10. That is, 10 bad periods, followed by five good periods, followed by 10 bad periods, results in a bad period count of 15. 

Within each sample period, Global Mirror writes are assessed. If in a write operation, the delay added by the Global Mirror protocol exceeds the gmmaxhostdelay  value, the operation is counted as a bad write. Otherwise, a good write is counted. The proportion of bad writes to good writes is calculated. If at least one third of writes are identified as bad, the sample period is defined as a bad period. A consequence is that, under a light I/O load, a single bad write can become significant. For example, if only one write I/O is performed for every 10 and this write is considered slow, the bad period count increments. 

An edge case is achieved by setting the gmmaxhostdelay  and gmlinktolerance  parameters to their minimum settings (1 ms and 20 s). With these settings, you need only two consecutive bad sample periods before a 1920 error condition is reported. Consider a foreground write I/O that has a light I/O load. For example, a single I/O happens in the 20 s. With unlucky timing, a single bad I/O results (that is, a write I/O that took over 1 ms in remote copy), and it spans the boundary of two, 10-second sample periods. This single bad I/O theoretically can be counted as 2 x the bad periods and trigger a 1920 error. 

A higher gmlinktolerance  value, gmmaxhostdelay  setting, or I/O load might reduce the risk of encountering this edge case. 

## maxreplicationdelay and partnershipexclusionthreshold 

IBM Spectrum Virtualize version 7.6 has introduced the maxreplicationdelay  and partnershipexclusionthreshold parameters to provide further performance protection mechanisms when remote copy services (Metro Mirror and Global Mirror) are used. 

maxreplicationdelay  is a system-wide attribute that configures how long a single write can be outstanding from the host before the relationship is stopped, triggering a 1920 error. It can protect the hosts from seeing timeouts due to secondary hung I/Os. 

This parameter is mainly intended to protect from secondary system issues. It does not help with ongoing performance issues, but can be used to limit the exposure of hosts to long write response times that can cause application errors. For instance, setting maxreplicationdelay to 30 means that if a write operation for a volume in a remote copy relationship does not complete within 30 seconds, the relationship is stopped, triggering a 1920 error. 

