1 /CHECKSUMMING
/CHECKSUMMING
/NOCHECKSUMMING
Enables or disables checksum verification on the selected VCs to
the specified nodes.
You can use this command alone or in combination with the system
parameter NISCS_PORT_SERV. (For more information, see online help
for NISCS_PORT_SERV.)
Note that the the SET VC/CHECKSUMMING setting is not valid beyond
the life of the system. Therefore, you might want to include SET
VC/CHECKSUMMING commands in your startup file, or reissue these
commands at the next boot.
2 /COMPRESSION
/COMPRESSION
/NOCOMPRESSION
Enables or disables sending compressed data by the specified VCs.
The default is /NOCOMPRESSION.
Usage notes:
o Compression is used only if the partner node has a PEdriver
version that supports it.
o You can also enable the use of compression with the NISCS_
PORT_SERV system parameter. For more information about NISCS_
PORT_SERV, see the System Parameter appendix in this manual.
o The /NOCOMPRESSION qualifier does not override compression
enabled by setting bit 2 of NISCS_PORT_SERV.
3 /ECS_MAX_DELAY
/ECS_MAX_DELAY=n
/NOECS_MAX_DELAY
Sets a management-specified lower bound on the maximum delay (in
microseconds) an ECS member channel can have. The value for n can
be any value between 0 and 3000000. /NOECS_MAX_DELAY disables a
prior management delay setting.
You can use this command to override the PEdriver automatically
calculated delay thresholds to ensure that all channels with
delays less than the value supplied for n are included in the
VC's ECS.
The command operates as follows: Whenever at least one tight peer
channel has a delay of less than the management-supplied value,
all tight peer channels with delays less than the management-
supplied value are automatically included in the ECS. When all
tight peer channels have delays equal to or greater than the
management setting, the ECS membership delay thresholds are
automatically calculated and used. The /NOECS_MAX_DELAY qualifier
disables management control by setting the management delay value
to zero.
You must determine an appropriate value for your configuration by
experimentation. An initial value of 2000 (2 ms) to 5000 (5 ms)
is suggested.
CAUTION
By overriding the automatic delay calculations, you
can include a channel in the ECS whose average delay is
consistently greater than 1.5 to 2 times the average delay
of the fastest channels. When this occurs, the overall
VC throughput becomes the speed of the slowest ECS member
channel.
An extreme example is when the management delay permits a
10 Mb/s Ethernet channel to be included with multiple 1 Gb/s
channels. The resultant VC throughput drops to 10 Mb/s.
Note that the SET VC/ECS_MAX_DELAY setting is not valid beyond
the life of the system. Therefore, you might want to include SET
VC/ECS_MAX_DELAY commands in your startup file or reissue these
commands at the next boot.
4 /EXCLUDE
/EXCLUDE=(nodename[,...])
Excludes VCs to specific nodes, which you can use wildcards to
specify.
5 /WINDOW
/WINDOW=RECEIVE=n
/WINDOW=NORECEIVE
Sets a management-specified upper bound on the receive window
size (that is, the number of out-of-order packets this VC holds
in its resequencing cache while awaiting the next in-order packet
or packets).
You can use this qualifier to override the automatically
calculated receive window size. This ensures that the VC has
enough buffering to receive the expected maximum number of out-
of-order packets.
Usage notes:
o The window size value n must be an exact power of 2.
Never use settings that cause the receive window of a VC to
be smaller than the transmit window of the partner node.
Otherwise, the partner can send packets that cannot be
cached when a packet is lost. This results in unnecessary
retransmissions, and might cause channels not to be used
because they become "lossy." This leads to the remaining
restrictions listed.
o Always decrease the receive window size of a VC's partner node
before decreasing a VC's receive window size.
VSI recommends using SYSMAN to decrease both the local and the
remote VC transmit window sizes before increasing the local
and remote receive window sizes (as shown in the example).
o Always increase the receive window size of a VC's partner node
before increasing a VC's transmit window size.
VSI recommends using SYSMAN to increase both the local and the
remote VC receive window sizes before increasing the local and
remote transmit window sizes.
o Whenever you enter the SET VC/WINDOW=RECEIVE command, the
following sequence of events occurs:
1. The VC's current resequencing cache is emptied.
2. The VC partner node automatically retransmits any discarded
packets.
3. As a result of 2, the VC and channel retransmit counts
increase.
4. A few messages similar to the following might be displayed,
indicating that one or more channels has temporarily become
"lossy":
%PEA0, Excessive packet losses on LAN Path from EWA to EWC
on REMOTE NODE STAR
5. The partner node recovers automatically within a few
seconds.
o You can use the SCACP> CALCULATE WINDOW_SIZE command to assist
you in selecting the size to use for transmit and receive
windows.
6 /WINDOW
/WINDOW=TRANSMIT=n
/WINDOW=NOTRANSMIT
Sets a management-specified upper bound on the transmit window
size (that is, the number of out-of-order packets this VC sends
while awaiting acknowledgment of the transmitted packets) to n.
The /WINDOW=NOTRANSMIT qualifier resumes automatic control of the
window size and changes the management transmit window size to
zero.
You can use the /WINDOW=TRANSMIT qualifier to override the
automatically calculated transmit window size to ensure that the
VC has enough buffering to receive the expected maximum number of
out-of-order packets.
Usage notes:
o The window size value n must be an exact power of 2.
Never use settings that cause the receive window of a VC to
be smaller than the transmit window of the partner node.
Otherwise, the partner can send packets that cannot be
cached when a packet is lost. This results in unnecessary
retransmissions, and might cause channels not to be used
because they become "lossy". This leads to the following
restrictions.
o Always decrease the transmit window size of a VC's partner
node before decreasing a VC's receive window size.
VSI recommends using SYSMAN to decrease both the local and the
remote VC transmit window sizes before increasing the local
and remote receive window sizes.
o Always increase the receive window size of a VC's partner node
before increasing a VC's transmit window size.
VSI recommends using SYSMAN to increase both the local and the
remote VC receive window sizes before increasing the local and
remote transmit window sizes (as shown in the example).
o You can use the SCACP CALCULATE WINDOW_SIZE command to assist
you in selecting the size to be used for transmit and receive
windows.