Chapter 11. Advanced Copy Services 599
11.11  Troubleshooting remote copy
Remote copy (Metro Mirror and Global Mirror) has two primary error codes that are displayed: 
/SM590000A 1920 error can be considered as a voluntary stop of a relationship by the system when it 
evaluates the replication will cause errors on the hosts. A 1920 is a congestion error. This 
error means that the source, the link between the source and target, or the target cannot 
keep up with the requested copy rate. The system then triggers a 1920 error to prevent 
replication from having undesired effects on hosts.
/SM590000A 1720 error is a heartbeat or system partnership communication error. This error often is 
more serious because failing communication between your system partners involves 
extended diagnostic time.
11.11.1  1920 error
A 1920 error is deliberately generated by the system and should be considered as a control 
mechanism. It occurs after 985003 (“Unable to find path to disk in the remote cluster (system) 
within the time-out period”) or 985004 (“Maximum replication delay has been exceeded”) 
events.
It can have several triggers, including the following probable causes:
/SM590000Primary system or SAN fabric problem (10%)
/SM590000Primary system or SAN fabric configuration (10%)
/SM590000Secondary system or SAN fabric problem (15%)
/SM590000Secondary system or SAN fabric configuration (25%)
/SM590000Intercluster link problem (15%)
/SM590000Intercluster link configuration (25%)
In practice, the most often overlooked cause is latency. Global Mirror has a round-trip-time 
tolerance limit of 80 or 250 milliseconds, depending on the firmware version and the hardware 
model. A message that is sent from the source IBM Spectrum Virtualize system to the target 
system and the accompanying acknowledgment must have a total time of 80 or 
250 milliseconds round trip. That is, it must have up to 40 or 125 milliseconds latency each 
way.
The primary component of your round-trip time is the physical distance between sites. For 
every 1000 kilometers (621.4 miles), you observe a 5-millisecond delay each way. This delay 
does not include the time that is added by equipment in the path. Every device adds a varying 
amount of time, depending on the device, but a good rule is 25 microseconds for pure 
hardware devices. 
For software-based functions (such as compression that is implemented in applications), the 
added delay tends to be much higher (usually in the millisecond plus range.) The following is 
an example of a physical delay.
Company A has a production site that is 1900 kilometers (1180.6 miles) away from its 
recovery site. The network service provider uses a total of five devices to connect the two 
sites. In addition to those devices, Company A employs a SAN FC router at each site to 
provide FCIP to encapsulate the FC traffic between sites. 
Now, there are seven devices and 1900 kilometers (1180.6 miles) of distance delay. All the 
devices are adding 200 microseconds of delay each way. The distance adds 9.5 milliseconds 
each way, for a total of 19 milliseconds. Combined with the device latency, the delay is 
19.4 milliseconds of physical latency minimum, which is under the 80-millisecond limit of 
Global Mirror until you realize that this number is the best case number.