| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 5135.1 | WAG | BSS::JILSON | WFH in the Chemung River Valley | Tue Oct 15 1996 13:59 | 1 |
| 5135.2 | ROFL | COL01::VSEMUSCHIN | Seva@COO, the Recycled Employee | Tue Oct 15 1996 14:12 | 8 |
| 5135.3 | looks like, that it is solved | COL01::VSEMUSCHIN | Seva@COO, the Recycled Employee | Tue Oct 15 1996 15:17 | 14 |
| 5135.4 | what is, when system disks are local ? | COL01::VSEMUSCHIN | Duck and Recover ! | Thu Nov 21 1996 04:45 | 10 |
| 5135.5 | something new about it ? | COL01::VSEMUSCHIN | Duck and Recover ! | Fri Jan 10 1997 10:15 | 17 |
| 5135.6 | SCS load balancing is Coming! | EVMS::PERCIVAL | OpenVMS Cluster Engineering | Fri Jan 17 1997 09:23 | 9 |
| 5135.7 | what I need NOW is simpe hardware workaround | COL01::VSEMUSCHIN | Duck and Recover ! | Mon Jan 20 1997 03:45 | 30 |
| 5135.8 | Any Data To Base These Questions On? | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Jan 20 1997 09:45 | 7 |
| 5135.9 | Some data | VIVIAN::RANCE | http://vivian.hhl.dec.com/rance/ | Mon Jan 20 1997 16:25 | 27 |
| 5135.10 | Looking for dual-DSSI info... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Mon Jan 20 1997 17:18 | 14 |
| 5135.11 | any data to base these questions on | COL01::VSEMUSCHIN | Duck and Recover ! | Tue Jan 21 1997 05:17 | 51 |
| 5135.12 | Some explanations | VMSSPT::JENKINS | Kevin M Jenkins VMS Support Engineering | Tue Jan 21 1997 07:41 | 37 |
| 5135.13 | one of question was little different from those you answered | COL01::VSEMUSCHIN | Duck and Recover ! | Tue Jan 21 1997 08:30 | 25 |
| 5135.14 | I don't have many test configs | VMSSPT::JENKINS | Kevin M Jenkins VMS Support Engineering | Wed Jan 22 1997 08:07 | 13 |
| 5135.15 | OK | COL01::VSEMUSCHIN | Duck and Recover ! | Wed Jan 22 1997 09:55 | 5 |
| 5135.16 | some experiences with port_class_setup_axp.exe | COL01::VSEMUSCHIN | Duck and Recover ! | Mon Apr 07 1997 08:29 | 46 |
| I tried port_class_setup in the following configuration:
ALF1 KFESA - PAA0: <---> PAA0: - KFESA ALF2
AS1000A 5/300 KFPSA - PIA0: <---> PIA0: - KFPSA AS1000A 5/300
256 MB KFPSA - PIB0: <---> PIB0: - KFPSA 256 MB
OVMS 6.2-1H3 DEFPA - PEA0: <===> PEA0: - DEFPA OVMS 6.2-1H3
PAA0: is free (only cable among two computers). PIA and PIB each
has an HSD50 attached.
After boot anything was OK, until PIA0: closed the virtual circuit.
Then VMS$VAXcluster changed to PAA0:. We (customer and I) tried to
use PORT_CLASS_SETUP to change the load class on PI adapters to 0x1A.
First PIA0 then PIAB0. After that all SYSAP's are were concentrated
on PIA0:. PIB0: as well as PAA0: was idle. Degrading the load class
of PIA0: 0x19 (both computers) didn't help. Raising the PIB's load
class to 0x1B (on ALF2) forced VMS$VAXcluster to PAA0: (whose load
class was never changed - 0x14) and all others SYSAP's but MSCP$DISK
to PAB0:. After raisin the load class of PIA0: from 0x19 to 0x1B
VMS$VAXcluster joined MSCP$DISK on PIA0:. After that I rose the load
class of PIA0: on ALF1 to 0x1A without any effect to SYSAP's ...
I think the reason why SYSAP's were concentrated on PIA0 was lack of
dynamic load balancing on Alpha's. But I thought, that at least some
disk or tape SYSAP's could be left on PIB0 because it has some disks
attached (HSD50). Why not ?
Why I lowered the load class on PIA0: without any effect on SYSAP's ?
Was it the feature of PORT_CLASS_SETUP or side effect of load balancing
(or better to say lack of it) on Alpha's ?
Third question is why when I rose load class on PIA0: VMS$VAXcluster
gone to PAA0: ?
And why MSCP$DISK was left on PAA0: ? It was exactly what I want to
achieve - some SYSAP's on PIA other on PIB, but why one time after the
raising of load class ALL SYSAP's are concentrated on interface with
the highest class (it was PIA0) and at the other time only SOME of them
changed to the PIB0 (owner of the highest class) ?
TIA
=Seva
|