How LIM determines host models and types
The LIM (load information manager) daemon/service automatically collects information about hosts in an LSF cluster, and accurately determines running host models and types. At most, 1024 model types can be manually defined in lsf.shared.
If lsf.shared is not fully defined with all known host models and types found in the cluster, LIM attempts to match an unrecognized running host to one of the models and types that is defined.
LIM supports both exact matching of host models and types, and "fuzzy" matching, where an entered host model name or type is slightly different from what is defined in lsf.shared (or in ego.shared if EGO is enabled in the LSF cluster).
How does "fuzzy" matching work?
LIM reads host models and types that are manually configured in lsf.shared. The format for entering host models and types is model_bogomips_architecture (for example, x15_4604_OpterontmProcessor142, IA64_2793, or SUNWUltra510_360_sparc). Names can be up to 64 characters long.
When LIM attempts to match running host model with what is entered in lsf.shared, it first attempts an exact match, then proceeds to make a fuzzy match.
How LIM attempts to make matches
Architecture name of running host |
What the lim reports |
Additional information about the lim process |
---|---|---|
Same as definition in lsf.shared (exact match) |
Reports the reference index of exact match |
LIM detects an exact match between model and input architecture string |
Similar to what is defined in lsf.shared (fuzzy match) |
Reports fuzzy match that is based on detection of 1or 2 fields in the input architecture string |
|
|
||
|
||
Has an illegal name |
Reports default host model |
An illegal name is one that does not follow the permitted format for entering an architecture string where the first character of the string is not an English-language character. |