Sierra Video Yosemite - Manual (Page 76)

SIERRA VIDEO
70
Redundant Processor Status and Terminal “T” Screen
Terminal protocol provides a way to examine the status of the redundant processors. This is done by
entering “T” to display the redundant processor status screen. See Terminal Protocol. Remember that the
screen is being produced by the master processor, including controlling the display of terminal protocol
screens. The redundant processor information screen displays the following information:
 Whether or not a standby processor is available. It must be healthy and present to be
available.
 If a standby processor is available, whether or not it has finished synchronizing up to the
master.
 Whether the current master processor is the preferred master or standby processor i.e. DIP
Switch setting S1-1.
 Whether or not the current master processor was synced with the previous master at the time
that it took over as new master.
 What circumstances caused this processor to become master: user requested processor switch,
master processor died, master processor became unhealthy, other processor didn’t respond at
power-up, or the current processor was the preferred master at power-up.
After displaying this information, the screen prompts the user to see whether or not the master processor
should shut down and the standby processor should take over. This question is only asked if a standby
processor is available. If the user answers “yes”, the master processor restarts itself and the standby
processor takes over.
Periodic Testing of Standby Processor
Although the LEDs indicate whether or not a processor has detected a problem with itself, it is still
possible that the processor can be unhealthy without the problems being detected. For example, a
processor might have a burned out control line for controlling the crosspoints, and it has no way to detect
this situation. Unless the customer takes steps to periodically test the standby processor, he can never be
sure that it is fully functional and ready to take over if the master processor goes down.
The only way to reliably test the standby processor is to force it to become the master processor. This can
be done with a host protocol command, or simply by using the terminal interface and the “T” screen
described in Software Protocol. As mentioned above, a switch from one processor to the other can cause
a temporary (several seconds) slowdown in system response. Therefore, switching should be done at a
time when it will not inconvenience users. It is not necessary to switch back again after making sure the
routing switcher continues to function properly with the other processor. Instead, you can simply switch
processors as often as once a month. Half the time the preferred master is in control, and half the time
the preferred standby is in control, creating a check test on both processors.