Set Maximum Number of Commands for the Gigabit Fibre Channel PCI Adapter
Problem
How much memory does the num_command_elements setting use and where is
that memory pulled from?
(i.e. SMIT screen chfcs: Maximum number of COMMANDS to queue to the adapter)
Solution
Set Maximum Number of Commands for the Gigabit Fibre Channel PCI Adapter
AIX Version 4.3 and 5L
Run the following command:
bus_intr_lvl 39 Bus interrupt level Fale
intr_priority 3 Interrupt priority Fale
bus_io_addr 0x5ec00 Bus I/O address Fale
bus_mem_addr 0xe0020000 Bus memory address Fale
lg_term_dma 0x200000 N/A True
max_xfer_size 0x100000 Maximum Transfer Size True
num_cmd_elems 200 Maximum number of COMMANDS to queue to the adapter True
pref_alpa 0x1 Preferred AL_PA True
sw_fc_class 2 FC Class for Fabric True
init_link al INIT Link flags True
The Gigabit Fibre Channel PCI Adapter Installation and Using Guide at the URL, http://publib16.boulder.ibm.com/pseries/en_US/infocenter/base/ hardware_docs/pdf/ 232550.pdf contains the following information:
Maximum Number of Commands to Queue to the Adapter: Use this option to adapt to various memory/system conditions. The default is 200, but you can conserve memory at the expense of performance by reducing this number to as little as 20. If you have sufficient memory, the maximum is 1024 for a Gigabit Fibre Channel PCI Adapter (Type 4-S). The maximum is 2048 for a 2-Gigabit Fibre Channel PCI Adapter (Type 4-W), as well as the adapter with Feature Code 6239 (Type 5704). If the SCSI target device is connected to the host through a SAN Data Gateway (SDG), then this parameter cannot exceed the SDG limit of 240 (SAN Data Gateway is a SCSI-to-Fibre Channel bridge).
This memory comes from kernel memory, which would be listed in svmon -S output as segment 0.
To change that parameter:
At that point, the lsattr output described above will reflect the new value, but it will not take effect until after the next reboot.
There are many different ways of testing the result of that change, by passing data through the adapter and checking the svmon -S output for the memory dedicated to segment 0.
Sample output:
0 - work kernel seg 4830 1881 769 4830
This indicates that there are 4830 pages (of 4K each) dedicated to segment 0.
Aucun trackbacks pour l'instant