CA2047573A1 - Dynamic computer system performance modeling interface - Google Patents
Dynamic computer system performance modeling interfaceInfo
- Publication number
- CA2047573A1 CA2047573A1 CA002047573A CA2047573A CA2047573A1 CA 2047573 A1 CA2047573 A1 CA 2047573A1 CA 002047573 A CA002047573 A CA 002047573A CA 2047573 A CA2047573 A CA 2047573A CA 2047573 A1 CA2047573 A1 CA 2047573A1
- Authority
- CA
- Canada
- Prior art keywords
- workload
- data structure
- computer system
- entries
- configuration
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/328—Computer systems status display
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3447—Performance evaluation by modeling
Abstract
ABSTRACT
A modeling system provides a display of a computer system's configuration along with selected system metrics.
An operator can change the configuration by using the display and display commands. Metrics representative of the performance of the computer system would then be determined for the changed configuration, and could presented along with the display of the new system configuration.
A modeling system provides a display of a computer system's configuration along with selected system metrics.
An operator can change the configuration by using the display and display commands. Metrics representative of the performance of the computer system would then be determined for the changed configuration, and could presented along with the display of the new system configuration.
Description
1 1¦ I. BACKGROUND OF T~ INVE~ION
; The present inven~ion relates to the field of automatic performance analysis and capacity planning and, more specifically, to the field of au~omatic performance analysis and capacity planning of computer sy~tems which have been modified in response to interactive operator input.
Performance analy~iq in computer systems is used to determine the effectiveness and efficiency of a computer ' system~s management of its workloads. The term ~'workload"
, refers to processes running on a computer system. Different types of processes are often treated as different workloads.
For example, word processing iq oft~n con3idered as one workload even though several computer sy~tem users are ~1 operating word processing program~. Similarly, ~preadsheets , could be considered a a distinct workload.
Each workload requires system re~ources, such as CPU
(central proce~sing unit) proco~sing time or disk capacity.
I' Performance analysis is designed to facilitate the management i! f such sy~tem resource~.
1l In carrying out performance analy~ls, one must always measure 30mo values for computer system and component ¦ par~meter~ in order to determine efficiency and efficacy.
The parameter~ being mea~ured have been referred to as ~ metric~ Example~ of metrics are ~he number of cache 2~wor~ misses in a particular time period, the number of page faul~s EC~ H ~DER~O~;; I
hR~30~' G~RR'rT ~ I
~D~ ER ;j in a particular time period, or the length of a device's ~00 ~ ~--R~ IV~ ~V
NI:ITON. OC 20005 ~O~O~.OOO -2-1.l 2.~1~7~ ! ~
1 j queue. Metrics are discusRed more fully in U.S. Patent No.
4,849,879 to Chinnaswam~ ~t al., which is incorporated herein by reference.
The metrics reflect the performance of the comp~Ater I system in a particular configuration. The term ~configuration~ used to refer not only to the types and interconnection of physical components, but also to the distribution of the workloads among the components.
I Most conventional methods of performance analysis and capacity planning involve presenting selected information in reports. The reports are usually tabular presentations of ,I data. Usually ~everal different kinds of reports are needed il for analysi~. For example, one rsport might indicate ~he ~¦ system configuration in term~ of component~, another report i~ might indica~e the system configuration in term~ of workload, 'I and another report may list certain metrics of interest.
il One performance analysis and capacity planning product which generate abular reports i~ the DECcp or DEC Capacity II Planner for V~S made av~ilable by DLgital Equipment i Corporation for u8e with certain VAX computers. This product l collects, reduces, analyzes, models and reports data in a ! tabular format for purposes of computer system capacity l planning. Another ~uch product i3 the VAX Performance I Advisor made available by Digital Equipment Corporation to 1 provide information u~eful in analyzing the performance of ~Aworrcc~ l certain VAX computers.
. INNEG~N, HENDER30~
F.'~RA30W G~RRETT ,:
~I DE'~i~lER j 1:~00 I ST~II:F;'. N W.
W~S~ GTON. DC ZOOO~ ~ j 1' 2~02 '10~ ~OOO , j _ 3_ r-7 ~
1 1 Although the tabular presentation of data may beacceptable ~or determining the performance of a computer system in one configuration, it does not lend itself well to analy~ing the performance of the computer system if its configuration were modified. Such analysi~ is importan~ in determining whether and how to reconfigure a system.
For example, if performance analysis indicated an overload or bottleneck condition in a computer system, the I system should be tuned or reconfigured to alleviate such i conditions. It is not always apparent, however, which tuning or reconfiguration is th~ most appropriate. Physical reconfiguration of a system without knowing whether that reconfiguration will be effectiva is both impractical and 1'1 costly.
11 To avoid unnecessary or incorrect reconfiguration, system engineer~ try to con~truct a model based upon actual system parameters. In this way, modeling may be us~d to I measure the impact of certain actions on system performance '1¦ before physically reconfiguring a computor i3ystem.
1 Modeling can al80 be uised in i3alois. If a modeling technique were not too cumberi~ome~ salespeople could use it to determins whether additional components were needed for a il particular cu3tomor, or whether a customer' 8 problemis or l needs could be handled in other way8.
1 Convantional performanca analy~is sys~ems, howev2r, do ~w or~c~ ! not lend themselvei~ well to such ui3eR A common means of FINNEC'.N~ HE~;DERSO~
F~R~aD~;N~NERRRE~ 1~I performing modeling involves using the information gathered ~000 1 9T~ECr, N~ W. j j w~.glll~0TON. OC 2000~ ~
,z02~00.000 ,, ~4 'i ,~ 5 ~ `
1 1¦ as part of the performancs analysis to calculate th~ effect of roconfiguring a computer sy~tem. This i~ both time con~uming and inaccurate.
Systems such as the DECcp system will perform certain automated calculations, however, the calculations are presented in a tabular format, which may again require the use of several sheets or tables to analyze results.
therefore deqirable to provide a mechanism for I performance analysi~ that allows for a more meaningful ' presentation of performance information.
Another desire is to provide an improved mechanism for changing the configurations of the computer sy~em, at least in a virtual ~ense, to determine the effect~ of such changes.
', An additional de~ire would bo to provide an improved lS i mechanism for pre~enting the effects of the changes in; configuration in a manner which allows ready deci~ion making.
Additional advantages of this invention will be set , forth in part ln ths de~cription which follows and in part ¦ will be obvious from that description, or may be learned by I practice of this invention. The advantages of this invention ¦ may be realized and atta~ned by means of the ¦ instrumentalitiQs and combinations particularly pointed in ¦~ th~ aPp9nded claim8.
,1 ,¦ II. S~NaR~ OF TH~ INVEFTIO~
~ orrlc- i! To achieve the ob~ects and in accordanco with the 'EC~I, tlE~lDERsO~; I
~9D~;~G~ER~ETT ' purpose of the invention, a~ embodied and broadly described ~00 1 ~Q~Er. Y. ~.
3r~YOTOY :~C 2000~ ~
1`:02`40~ 000 ' _5_ ., , ~'i7~ j 1 ll herein, the present invention provides a display of a jl computer ~ystem's configuration along with selected system metric~. An operator can change the configuration by using the display. Metrics represen~ative of the performance of the computer system would then be determined for the changed configuration, and could be presented along with the display of the new sy~tem configuration.
More particularly, a method of evaluating the performance of a computer system described by a configuration ` representing physical devices, the connections of the physical devices in the computer system, and workloads which . are processes that use iystem resources provided by the physical devices, comprises the step~i, executed by a modeling ~ data proce3sor, of: creatirAg a model of the configuration of I the computer system in the modeling data proce~isor;
displaying, on a visual display device coupled to the data processor, a diagram of the configuration of the computer system; receiving an input to modify the configuration of the ` computer system; modifying the model of the computer system in response to tha received input to reflect the modifiod 1~ configuration of the computer system; determining new values !¦ of selected metrics for the modified model of the computer ~ y~tem, metrics includlng mea~urable values repre~entative of il th~ performance of the computer system; and displaying on ~he ~1 visual display devlce a diagram of the modified configuration .AwOrrc~g 1, of the computer system.
INNE~AN HENDER'jON ~ ¦
FARA90W. GARRETT
h DUNNER j ' 1300 ~ 9TREET, ~.1. W. , j W~lliOTOrl. I:IC 2000!S
1 202.40a-4000 ~ -6--1 .1 A data structure, according to the present invention, I for use in modeling a computer system con~aining a plurality of physical devices supporting a plurality of workloads resides in a modeling data processor and comprises a plurality of first data entries organized into an easily modifiable first data structure, each of the first data entries corresponding to a different physical device of the computer sy~tem, and a plurality of second daT~a en~ries ~' organized into an easily modifiable sacond data structure, each of the second entries corresponding to one of the workloads which the devices in the computer system support by supplying system resourcss to the workloads. The first entries include device identification means for identifying .j the corresponding physical device, and device data structure , means for indica~ing a hierarchical relationship in the computer system configuration of the corresponding device ` with selected other ones of the phy~ical devices. The second .` entrie~ each include workload pointer means for identifying , the corresponding workload, device pointer means for ~ associating the corresponding workload with the one~ of the ji devices supportinq the corresponding workload, and j probability mean2~ for quantifying the system resource ''i supplied to the corresponding workload by the associated one Il of the phy4ical devices.
j Additionally, a modeling system of thi~ invention for '^w or~.Cc~ i facilitating analy~is of a computer sy~tem comprise3: data ;EC~. HE~DE.~O~; j ~R~DW~ E~RRETr ' structure means for holding physical device information and 1300 ~ g~ W
w~ 0~0~. DC 20003 I`:02 '10~ 000 ~7L`t` :~`
1 1 workload information, both representative of the configuration of the computer system, and metrics information representative of the performance of the computer system;
I change means, coupled to the data structure means, for receiving requests to modify the physical device information;
!; solv~r means, coupled to the data structure means, for determining value~ for metrics information for the computer system from the physical device information and the workload information in the data structure means; and user interface 1l means, coupled to the change means and to the data structure means, for providing an interface to a user o~ the modeling Il system. The data structure means includes configuration ¦¦ context means for storing the phy~ical configuration informa-il tion and the workload information. The changer means lS l! includes data structure modification mean3 for transmitting to the data structure mean~, in respons~ to the received Il request~, commands to modify the representation of the Il computer sy3tem configuration. The user interface means !! include~ means for tran~mitting to the change means the requests to modify the phy~ical device information made by a u~er, and means for displaying a ~iagram of the configuration of the computer system, including value~ for the metrics ! information.
, III. BRIEE' DESCRIPTION OF THE DRAWINGS
, The accompanying drawing3, which are incorporated in and ~WO~ constitute a part of this specLfication illus~rate EC~; HE~DER5~: 1 ..~R.~B~W ~RRETT , ~mbOdiment8 of the inv~ntion and, togethar with the '300 ~ ST~667. N. W
W~9~1~N0701'J. DC 2000~ .!
1-20240d-4000 i! -8-!!
!l r f 1 1I description, ~erve to explain the ob~ects, advantages and 1l¦ principles of the invention. In the drawingq:
~I Figure 1 is a diagram of a computer system that can be modeled in accordance with the present invention;
Figure 2 is a display of the computer system in Figure 1 generated by a modeling interface of the present invention;
Figure 3 (a) is a diagram of one preferred implementation of the modeling interface of this invention;
Figure 3 (b) is a diagram Ol' another preferred implementation of the modeling interface of thi~ invention;
Figure 4 is a flow diagram of the gsneral operations in a preferred implementation of this invention;
Figures S (a) through 5(ii) are screen displays Il generated during the operation of the preferxed 1 implementation of the modeling interface of this invention;
j Figure 6 is an overview of the data structure used in the preferxed implementation of this invention;
Figure 7 is a diagram of a preferred implementation of a 1 device tree;
!I Fiqure 8 i~ a diagr~m of a prefarred implementation of a li ~eneric node for use in the data struCturQ of Figure 6;
Figure 9 is a preferred implemen~ation of a link array for u~e in the node of Figure 8;
1, Figure lO is a diagram of a linkage list represen~ed by ¦, the link array in Figure 9;
~ wo~r~cc~ li Figure ll(a) is a diagram of variant record for a model -INNECAN HENDERSO1~; I
FARAaOW GARRETT d 6 DUNNER I no e;
1300 t ST~EeT, N. W.
W~3~1t.15T0~.1. DC Z000~ j ' I 202 401~- ~000 li Il il 1 ' Fi~ure ll(b) is a diagram of an exemplary model node in l accordance with the present invention;
1 Figures 12(a) - 12(d) are examples of different model ,I configurations;
Figure 13 is a diagram of the variant record for a device node;
Figurs 14 is a diagram of a workload data tree showing ~1 its relationship to a device tree.
.l Figure 15 is a diagram of a variant record portion of a ,l workload node;
,I Figure 16 is a diagram of branch probability node;
¦¦ Figure 17 i~ a diagram ~howing relationship between nodes of device tree, a workload trQe and a user group tree, li~ Figuxe 18 i~ a diagram of u~er group data tree;
ll Figure 19 i~ a diagram of computer ~ystem using MSCP
jl feature;
,i Figure 20 is a diagram of an MSCP data tree;
,~ Figure 21 i~ a diagram showing the relationship between j MSCP data trees and a d~vice tree;
1¦ Figure 22 diagram of the variant record portion of an ¦ MSCP node;
Figure 23 i~ a diagram showin~ the relatlonship of portions of device tree nodes and MSCP tree nodes;
i Figure 24 include~ a generalized flow diagram 2400 1l explaining how this invention reacts to inputs from ,~w orrlc~- , ! operator~;
INNEG~N. HENDERSON j !
F.~RA80W. GAR RETT , ¦
~ DUNNER ¦ I
~300 1 5TQEET. N. W. ! j W~IN'3TON, I~C 2000!S
I~Z02~00~-000 ~ 0--I!
1 Figure 25 includes a flow diagram for the preferred i implementation of the FILE procedure shown in Figure 24;
Figures 26(a) and 26(b) include a flow diagram for the , preferred implementation of the SET proce~ure shown in Figure 24;
Figure 27 includes a flow diagram for the preferred implementation OL' the ADD procedure shown in Figure 24;
Figure 28 include~ a flow diagram for the pref~rred , implementation of the DUPLICATE procedure shown in Figure 24;
Figure 29 include~ a flow diagr~m for the preferred implementation of the MOVE procedure shown in Figure 24;
I Figure 30 is a diagram for explaining how the loads are " distributed according to the preferred implementation of the Il MOVE procedure in Figure 29, I Figures 31(a), 31(b), and 31~c) include a flow diagram 'I for the preferred implementation of the REMOVE procedure !I shown in Figure 24;
I; Figure 32 includes a flow diagram for the preerred I¦ implementation of the VIEW procedure shown in Figure 24;
ll Figure 33 includeQ a flow diasram for the preferred il implementation of the SOLVE proc~dure ~hown in Figure 24; and I¦ Figure 34 ~hows a forma~ for certain files with which ! il the par~e~ interface.
¦I rv. DESCRIPTION OP T~ P~F~RR~D r4P~E~TATI~
~I Reference will now be made in de~ail to the con~truction .AwOrrlcc~ ,~ and operation of preferred implementation of the present EGAt~: HE~:DER30~ l;
FARA30W. GARRETT ~ !
~D~ER ~, invention which are illu~trated in the accompanying drawings.
1300 ~ ST~EET, N. W.
w~5~1~10T0!1. DC 20005 ' ~ ZOZ .~09 .-000 !
!l 1 il In tho~e drawinqs, like elements and operations are de~ignated with the same reference characters.
! In the following description, the preferred ,l implementations described are examples of the present , invention. The present invention, however, is not limited to ' these examples, but may bt~ realized in other implementations.
A. SYstem Desian and OPeration 1. Com~uter svstem beinq modeled Figure 1 shows a diagram of a computer sy~tem 100 which I can be modeled and analyzed in accordance with the present invention. It should be understood tha~ computer system 100 Il is merely exemplary, and use of the pre~tent invention i~ not - limited to any particular computer syttem configuration.
ll System 100 contain~ two bu~se~, NI bu~ 103 and CI buT
1 106. NI bus 103 is profarably an Ethernet-type bus for high speed data communication among a pluxality of network nodes.
CI bus 106 is preferably a bu~ used to connect devices in a ,¦ cluster configuration. The details of a CI bus are de~cribed ,¦ in U.S. Patent No. 4,560,985 to StrecXer, st al.
1l Coupled to CI bu~ 106 and NI bu~ 103 axe CPUl 110, CPU2 l 120, snd CPU3 130. CPUl 110 has a bus interface 112 for i connect~on to NI bus 103, and a bus interface 113 for ¦¦ connection to CI bus 106. CPU2 120 hact a bus interface 122 I¦ for connection to NI bus 103 and a bu~ interface 123 for 1¦ connection to with CI bu~ 106. CPU3 130 ha~ a bus interface .Aworrlcc3 , 132 for connection to MI bu3 103.
EC~N~ HE~DERSO~;;
FARA30~. C~RRETT
8 D~ ER
1~00 t 9T~tEET N. W.
W~lNOTON~ 3C 20009 ,z02.0~000 ll -12-!
I1 2~7~ ;~
1 I HSC (hierarchical storage controller) 140 manages communication~ between disks and CI bus 106. HSC 140 ! includes two channels, channell 150 and channel2 155, each of which is connected to one or more disks. Channell 150 is connected to disks Dl 160 and disk D2 162. Channel2 155 is connected to disk D3 164.
In system 100, disk D4 166 is connected to CPUl 1 110.
Disk D5 168 and disk D6 170 are both connected to CPU3 130.
Figure 2 shows a computer generated display 200 of the computer system 100 shown in Figure 1. Display 200 in Figure 2 is generated on a modeling data processor. The modeling ` data processor can be one of the CPU~ in computer sy~tem 100, but need not be. The purpo~e of the modeling data processor l is to implement the processes nece~sary for performance 1 analysis and capacity planning in accordance with the present invention.
" Display 200 not only includes all of the busses, CPUs, HSCs, channel~, and disk~ of ~y~tem 100, but also includes Il information such as the ~ype of CPUs and HSC, and an identification of at lea~t one workload. As explained above, wor~loads are processas that use ~ystem resources.
!~ Associated with aach workload i~ one or more device branching probabilities. For each workload, there i~ a Ii branching probability associated with every de~ice that 2S `, provide~ sy3tem resource~ for ~or 3upports) that workload.
.~wO~cc~ -! The device branching probabillty ~or a workload and a device EC~I HE~DERSO~; ~
F~R8DW~;~G~ERRRETr ¦ representg the percentage or fraction of the system resources 1~00 I ST~ E T, N. w.
W/~irllNOT~-I. DC 2000~ !
202 40~' ~ ll -13-'i ~ O ~ 7 ~
, required by a workload that is supported by the corresponding device. For example, if C2U1 has a branching probability of 20% for workload 1, then 20% of the CPU processing resources ` required by workload 1 are supplied by CPUl 110.
I Two other concepts which are important to understand, but which are not shown in Figures 1 or 2, are user groups and MSCP protocols. A user group is a set of user~ which are organized together for some purpose, such as management. A
user group's workload i~ the ~um of the workloads created by I the individual user in the user group.
User groups al~o have branching probabilities for I workloads to which those user group~ contribute. U~er group 'i branching probabilities reflect the percentage or fraction of i each workload which i9 created by the corrssponding user group.
The MSCP, or mass ~torage communications pro~ocol, i~ a protocol which allows a process executing on one CPU to Ij accesq files on disks not connected to that CPU in a manner ij~ which i3 in~i~ible to the proce3s. A more detailed 1 description of tho MSCP can be found in U.S. Patent No.
¦l 4,449,182 to ~ubinson, et al.
¦I The modeling interface of the present invention ¦l acco~modate~ these and other concept~ and provides Il interactive cemputer ~ys~em modeling for performance analysis 11 and capacity planning. In accordance with thi~ invention, AwO~rc~ operator~ can view a represen~ation of a computer ~ystem INNEC~N HENDERSON I;
FARABO~'. ~ARRETT
~ D~NNER Ij configuration and then designate change to that 1300 ~ STREET, N. W. j I
WA91-UNGTON. DC ZOOO!I ¦
1 202-~100 -000 j !
ll 2 o ll 7 ~
1 jj configuration, such a~ the a~dition, removal, or ¦ reconfiguration of devices or workloa~s. The results of tho~e changes would then be determined and pre~ented 50 an operator can view the results.
Furthermore, the modeling and analysi~ can be performed according to user groups and can take in~o accoun~ the use of `I MSCP services. As the preferred implementations demonstrate, the present invention also allowq the workloads to be altered ' either by specific workload, by user group workload~, or 1 acros-~ all workloads.
In addition, when certain changas to a system are made, I the workloads can be automatically redistributed in ! predetermined manners. Thi can be accomplished while still ¦ allowing an operator to fix certain branching probabilities.
1l 2. Modelin~ in~erface overview.
Figure 3ta) shows a preerred implementation 300 of a modeling interface in accordance with the present invention ~I which can provide the~ features described above. In the ',l preferred implementation, modeling interface 300 receive~ its I input about a computer system configuration from an .MDL file 305.
~ho .MDL file could be generated in many different ways.
One way i~ de~cribed in U.S. Patent No. 4,849,879 to Chinna~wamy et al., di~cu~ed in the Background of the Invention. Other technique for generating the configuration -I~NE~ HENDER50N i information are also po8Ribl~.
F.~R.~30W G~RRETT
~i DIIN~ER
~00 1 5TI~EET. N.
W~INOTON. OC 20005 i JIIJZo;l ~OO-~OOO I~
ll 2~ 3'~
Il 1 ¦¦ The output of modeling interface 300 is another .MDL
file 345. In the preferred implementation, .MDL files 305 and 345 have the same format but different data. .MDL files 305 and 345 preferably contain two types of data. One ~ype of data, device data, describes the devices in the computer system being analyzed as well as the interconnection of those devices. The other type of data, workload data, describes the workload~q on the system including information on workload distribution by use group and device. The specific format of the .MDL file, however, is not important to the present i invention.
In addition, initial values of per~ormance metrics can be supplied, but such value~ are not necessary to the present ! invention. If such inLtial valueY are supplied, they can be lS ¦I provided in the .MDL file or in qome other file.
Modeling interface 300 is a preferred implementation of the modeling system of the present invention. Modeling interface 300 includss parser 310, data storage 315, di~play/
'` keyboard 320, changar 330, QNM solver 335, and par~er 340.
~, Parser 310 is u~ed to translate ~he data from the format ¦~ stored in .MDL file 305 into an appropriate format for ,I storage into data storage 315. AR such, par~r 310 acts as a ~I type of compiler.
¦I Data storage 315 stores in a structure context portion 1~ 317 information on the configuration of the computer system ~ AwOrrc~ il being modeled and analyzed, as well aq information on I~;~E~A~ HE~;DER~O~
F.^RABOW. C~RRETT 11 ~ D~N~ER !; workloads, user group~, and MSCP relationship~. Data storage 1000 I gTRl:ET, N. W.
W~S~INGTON, 0C 20005 : .
1 202'400'-000 ,;
1, I I 2 0 ~L r~
1 11 315 ~tores that information in an easily modifiable form, preferably in a type of tree ~tructure, so that ch~nges to i the configura~ion can be easily effected. Data ~torage 315 i also contains performance metrics of interest in structure context portion 317.
; Data storage 315 also includes a display context portion 318 which contains information about the data being displayed. For example, display context portion 318 preferably includes information regarding screen position, , object being displayed, and performance metrics being ~ displayed.
" Di~play/keyboard 320 include~ a scxeen to di~play the configuration of the memory ~ystem, including information l~ about the system device~, the interconnection of thosa jl devices, and the worklo~d~. Display/keyboard 320 can also display information about u~ex groupc and performance metric~. All of the information di~played by display/
Il keyboard 320 i ba~ed on the information stored in the 1, structure con~ext portion 317 and display context portion 318 1l of da~a storage 315.
¦ Display/keyboard 320 includes di~play logic 322 which j~ acce3aes the information from display context portion 318 and structure context portion 317 to generate the di~play~.
l Ba~ically display/keyboard 320 acces es di~play context portion 318 to determine what information from ~ructure AwOrrccO l¦ context portion 317 to display and how to display that . INNIECAN. HENDER50~ ¦ !
FARAEOW. GARRETT , j I~DwNER !l 1300 ~ STR~E8 N. W.
W39~1NGlON OC 2000 ~202 408-4000 Il -17-I 2 13 ll ji j il, 1 ll information. The hardware and software to implement suchfunc~ion are known to persons skilled in this art.
Display/keyboard 320 also receives inputs from operators ~ requesting modeling interface 300 to modify the configuration or to perform other tasks. Those input~ can be received from keyboard commands or from devices, such as a mouse, which allow for screen selection. The inputs are buffered and I output by keyboard logic 323 to data storage 315, changer 330, and QNM solver 335.
`I Changer 330 receives the input from display/keyboard 320 and converts those requests into set~ of commands for other elements of modeling interfac0 300, such as data Il 3torage 315. At the appropriate time, changer 330 al80 ¦1 causes the necessary data from d~ta storage 315 to be I transmitted to QNM solver 335.
QNM solver 335 receives from data storage 315 modeling jil information describing the configuration of the computer I system being analyzed. That modeling information also jl includes workload parameter, uYer group information, MSCP
1I relation~hip~, and ~y~tem parameter3. From the modeling ¦1 information, Q~M solver 335 determines what certain performance metrics would be for a system operating according to the recaived modeling information. QNN solver 335 then ll store3 tho~e performance metric~ back into data storage 315.
'1I Parser 340 acts in a manner complementary to parser 310 ~worrlcc, by tran~forming the information from the format of data iECA`I. HE`iDER~O~ j 8D~;~ER ! storage 315 format back into the .MDT. format. In response to 1300 I STREET, N. W~ j i WA9NINOTON. DC 20009 I `Z02 .-09-. 000 1 i , I
~7~ ~
1 ¦ an operator request recei~ed from display/keyboard 320, data sTorage 315 transmits the configuration and metrics ~ information through parser 340 into .MDL file 345.
I Figure 3(b) shows an al~ernative implementation, modeling interface 350, in accordance with the present invention. Modeling interface 350 differs from modeling interface 300 in its use of parsers already employed for the .MDL files.
Il As in modeling interface 300, .MDL file 305 provides ~1 input and the .MDL file 345 recei~e~ the output from the modeling interface 350. Parser 360 i a parser u~ed in conventional systems for .MDL file Parser 360 translate~
~i the .MDL file 305 into an array. An interface 365 i8 added ¦ to parser 360 to provide final translation from the array ll into trees for data storage 315.
Another standard par~er 3gO i~ added to convert the , information from the tree format used by data storage 315 'I into array format3 for QNM ~olvex 335. Parser 390 also is Il u~ed to convert information from the array format which is an ¦¦ output QNM ~olver 335 back to the tree format used by data ~torage 315. Thi~ conversion also involves interface 365.
~¦ Finally, par~er 390 provide~ data conversion from the tree I¦ format for data ~torage 315 into a format for 3torage into !1 .MDL fila 345.
1; 3. Modelina intarface operation.
~WO~C~ Figure 4 is a flow diagram 400 generally howing the ~ D~;NNER ¦! 8tepQ performad during op~ration of th~ preerred 1300 1 5T~ ~, N. W. . i WA9~1NOl'ON. DC Z0009 I j ~ 20Z'~0~ 000 l j -19-1 ,l implemen~ation 300 of the present invention. At ¦ initialization of the operations represented by flow diagram , 400, the modeling interface receives from the computer system ! being modeled data describing t~e computer system~s configuration (step 405). As explained above, in the preferred implamentation, this informatLon is contained in the .MDL file 305.
In addition, if the option is chosen, the modeling , intexface in accordance with the present invention can il receive initial values for selected metrics for the computer system (step 410). The~e metrics would preferably be part of DL file 305, bu~ they could ~o provided in other way~, ~uch ~i as by operator input through a di~play/keyboart 320, or by ~ input from a differen~ file. The initial values of the l metrics received from the computer system will generally be values that were actually measurad during the operation of .l the computer ~ystem.
Il In a preferred impl~menta~ion, this receipt of 1 information i~ accompli~hed by choo ing a FILE option from a il modeling interface main menu 500, shown in Figure S(a), that ¦ appe~r~ on display/keyboard 320. Main menu 500 preferably allow~ ~eloction of one of ~everal options. In addition to j tho FILE option, there is al~o a S~T option, an ~DD option, a Il MOVE option, a REMOVE option, a DUPLICAT~ option, a VIEW
j option, and a SOLVE option. Thase options will be de~cribed ~worrlcc~ !l in greater detail below.
~IN1`:ECA~; HENDER50N 1 FARABOW G~RRETT
1300 ~ gTQIEl!:T. N. W. . ~
W~I~INOl'ON. 0C 2000~ 1, 1~202'~09 4000 ' ' 2 ~3 L~ 7 ~
1 I The FILE option is preferably selected by standard '¦ method~ of moving a cursor to a desired location on a menu displayed on display/keyboard 330 and then indicating a I selection. Once the FILE option is selected, a submenu S I appears that gives an operator a choice either to load a ;I model file (FILE LOAD), such as the .MDL file, into data storage 315, to write the model file to an .MDL file on a disk (FILE WRITE), to exit the modeling session and some the I changes in an .NDL file (FILE EXIT), or to exit the modeling .¦ session without saving the changes (FILE QUIT).
When the FILE LOAD option is chosen, ~he name of the i file mu~t also be provided. When the FILE WRITE option, FILE
!i EXIT option, or FILE QUIT option is choRen, no other Il information is needed. Choosing the FILE WRIT~ option does lS 'I not end the modeling session, but choosing ~he FILE EXIT and ! ¦ FILE QUIT options do.
Returning to Figure 4, after receipt of the configuration and initial parameter information, a model of I¦ the computer ~ystem configuration i8 created in modeling ¦1 int~rface 300 from the received information (step 415).
Preforably, either parser 310 in Fiqure 3(a), or the combination of parser 360 and interface 36S in Figure 3~b), build the model of the computor system configuration by placing the received configuration information into ~he ~; proper format for ~torage in data ~torage 315. The details L~W orrlC~ i I of the data format and preferred structure in data storage INNECAN. HENDER50~; ! I
F.~R.~80W. CARRETT ~
L~ DU~ER ! 315 are dlscussed below.
1300 ~ gTRCET. '1. W.
W~3111NOTON. DO 20003 1 1`202 40!~ -000 1 21-I
7 ~ 1 ?
, ext, a diagram of the configuration of the computer ! system, i~ di~played on display/keyboard 320 (~tep 420).
Ini~ial ~alues of certain selected metrics may also be displayed if such values were provided. Figures 2 and 5(b) show examples of such a display. Figure 5(b) is a diagram of a model display 505 showing workload information, workload parame~ers, devices, and performance metrics.
~odel di~play 505 preferably include~ a ~tatu~ lin~ 506, a list of workloads 507, and a di~play of the current model 508. One of the workloadq (Workload l), called a curren~
workl~ad, is highlighted. The information in ~tatus line 506 ` preferably includes the dioplay mode, the name of the model, i the name o~ the current workload, and ths name of a sourca I CPU. The display mode, a3 explained in greater detail below, I specifies which data is displayed in model display 505. The source CPU is the originator of the portion of the current workload.
Figure 5(c) show3 a m~s~age window 509 which is Il preferably overlaid on model di~play 505. Message window 509 jj includes message text, ~uch as messsge~ either from the modeling interface itself, broadcast messages, 6uch a~
¦ electronic mail, or operator mes~age~.
gure S(d) show~ a statu~ window 510 which can be !I di~played by making appropriate ~election~ on display/
1I keyboard 320. The statu~ window preferably provida~
.~vOrrlccg 11 information about the current CPU, the current workload, the Fl~ ;EGAI~; HE~DERSO~;
FARA~O~:C'. 5ARRET~ I
~ DU~ER j display mode, the balancing mode (explained below)~ the ~300 I ST~EEr, N. V.
~VASIllNOrON DC 20005 1 ~
202 ~0S " ' 22--!
., ~ ~3 '~
i 1 1l configuration being modeled, the status of the model, whether ¦ the mod~l has been solved, whether the model ha~ been " modified, and the name, if any, of the model library. The ,I model library is a library which overrid~s the default parameters of the devices modeled. Thi~ allows an operator to modify device parameters in the model.
After display of the system, the next step in flowchart 400 is the receipt of an input to modify the configuration of , the computer system (Step 425). The inputs can either ~ indicate a modification in the number and types of workload, the distribution of the workload, the number and type~ of ~I physical devices, or the connection of tho~e devices.
jl The preferred manner of making changes T~O the workload il involve~ use of the 5ET option from main menu 500 in Figure ¦ 5~a). The SET option allow~ an operator to set variou~
I parameters for the workload~ or variou~ attrlbutes for the ¦ modeling se~8ion.
I one of the SET options i~ the SET Di~play Mode option 1 which determines what information will be displayed for an ,1 identified ob~ect. In the preferred implementation, the SET
Display Mode option allows an operator to choose to display l branching probabilities, rate~ such as in TPS (tran~actions i per second) or IOs/second, percentage utilization, ~ervice I time (time to proce~ a reque~t) respon~e time (~ervice time ~1! plu~ queuing delay), yueue len~th, throughput (in IO t~ec)~
~wO~c~ and type3 of device3.
;EG~. HE~:DERSO
F.~R~90W. G~RRETT
8 DU~ER 1 1300 I STI~EI T, N. W. ' W~NOTON. DC 20005 ¦ ¦
t!Z02 ~0~ 4000 I j - 230 i l li '~ 2l3~7~j l 3 1 li In the preferred implemen~ation~ two of the display mode~, percentage utilization and queue length, will result in tha values flashing on the screen to indicate possible I problem condition~ The u~ilization value will flash if it exceeds a saturation point, which is set by default to 90~.
The queue length value will flash if 2 or greater.
In addition, when any changes are made to the model that might affect the performance metrics, such as the removal of ~ the device, the performance metrics that may be affected are ;' displayed in bold text to indica~e that they represent stale data.
Figure 5(e) i~ a diagram of a di~play 511 that would appear on display/keyboard 320 if the SET Display Mode option ~i were chosen. The different types of Display Modes are shown I in a window overlay, and the presentation of the ~probabilities~ entry in revar~e text indicates tha~ this is the Display ~ode being chosen.
Upon choosing the probabilities Di play Mode, a di~play l! 512 shown in Figure 5(f) would appear. Next to the ¦ representation of each device i9 in di~play 512 i~ a value in ¦¦ parentheses rapresenting the branching probability of that device for the current workload. In Figure 5(f), the current ¦ workload i~ workload-1.
llIf the SET Current Workload op~ion is chosen, a screen ji515, such as shown in Figure 5(g), i8 genera~ed showing the AW orr-cr~ Current Workload" option highlighted in rever~e text.
-INNECAN HENDERS;)N I;
FARABOW GARRETT j I
~i 3~'NNER
1300 1 5T~EEr. N. W. . j W~1~.070~. OC 2000 r202 ` ~03- 4 !
2 ~ ll 7 ~
1 1I The selection of ~he ~Curxent Workloadl~ option causes a I¦ diYplay 517, shown in Figure 5(h), to appear on display/
il keyboard 320. Display 517 allows an operator to choose to I display ei~her a designated workload or source CPU.
. If the Source CPU option is chosen, as indicated by the reverse text in display 517 of Figure 5(h), then a display 518 as shown in Figure 5(i) appears on display/~eyboard 320.
Display 518 shows the various CPUs in the computer system I being modeled.
I The operator would then choose one of the CPUs, such as .I CPU-5 in display 518 of Figure 5(i)l as shown in the reverse ',¦ text. This choice i~ then reflected on the sta~us line in display 519 of Figure 5(~).
I If a new workload or Source CPU i~ ~elected during the 1l SET Current Workload option, the information displayed in I paren~heses on the displayY will likely change if the Di~play ¦ Mode is "probabilitLes," or "TPS & IOs/sec." This is because ¦¦ the information di~played in the~a Display Modes represents a ,I percentage or actual I/O rate from the curren~ Source CPU and i workload. Changing the CPU or workload would likely force a changa in tho corre-~ponding information.
If the SET Balancin~ Node option is chosen, then a . di~play 520 as sho~n in Figure 5(k) apps~rs, which allows the ! Balancing Mode to be qet. The Balancing Node determine~ how ~5 . workloads should be redi~tributed among ~hs devices in a .,worrlc~ model when a change i~ made to the model that will affect FIN~EGA~; HE~:DERSO~
8 D~ER .I that workload. For exampl~, the removal of a disk causes the 1300 ~ STREET. 11. W.
W~9Y~I`IOTO~. DC 20005 j I 20Z''1O~ 000 --25 'r~ 7~
1 ,i I/O for each workload on that disk to be shifted to other l di~ks connected to the same CPU or HSC device. How the workloads are redistributed is determin~d by the Balancing ! ~ode.
` Workload distribution involves branching probabilities.
; As explained above, branching probability is a percentage of work supplied by a device for a given workload. Before solving a model, the branching probability for each workload must equal 100~. The probabilities can either be FIXED at a specific value or FLOATING. FLOATING probabilities can be adjusted to ensure that the sum of all related branching probabilities equals 100~. The balancing mode recalculations only affect the probabilities that are FhOATING.
'IIn the preferred implementation, a workload on a device lS such as a CPU or di~k can be apportioned among other devices jj in a set of device~ in two different ways. The relevant set jl of devices are those which can supply a greater or lessor i, amount of system re~ources to a particular workload. The set 1~ of devices would not include those with a FIXED probability.
I In uniform apportionment, the total amount of the ¦¦ ad~u~tment made for a dovice is divided equally among the !I device~ in the set. For example, if there were three CPU~, ¦11 and the branching probability for one CPU dropped by a II certain amount, the remaining two CPUs would have their ~I branching probabilitie increased by an amount equal to half ~AwOr~c~, ,! of the amount ~hat the first CPU's branching probability . INNE~AN HEN'DERSON ~ ¦
FAR.~aOW. G~RRETT l; d d ~ D~NNER I I roppe .
1300 I STRI:ET, N. W.
WAI~ OTO~. OC 20001 1 .
~`202 40~ 4000 , --26--!
7 .j ~ ~
1 I In relative apportionmen~, the total amount of the ad~u~tment i8 made proportionate ~o the ratios of branching probabilities the de~ices in ~he set. This insures that the ratios of branching probability for the devices in ~he 5et remain the same. In other words, if one of the two CPUs in the prior example has a branching probability for a workload which is twice as large a~ that of the other CPU, then two-thirds o f the workload needing to be allocated would go to the CPU with the larger branching probability.
Related to the SET Balancing Mode option i9 the SET
Probability Distribution option. If thi~ option is chosen, a display 522 a~ shown in Figure 5(1) appear~ on display/
keyboard 320. Di3play 522 pre~ents the operator with a choics of devices for which to ~et the probability. By the reverse text, display 522 shows that the operator has chosen to set the branching probability for a CPU. The next display to occur, which i5 not ~hown, contain~ a list of all the CPUs whose branching probability can be changed. When an appropriate CPU iY chosen, then the operator is prompted to i enter the branching probability for that CPU (or other device ! I cho en). In addition, in the preferred implementation, the opera~or i3 prompted to set the probability to FIXED or FLOATING.
Branchin~ probabilitie~ may al~o be modified indirectly l by deleting hardware and moving workload~ between device~.
~O~r~CC~ ¦ When the modeling interface i~ fir3t invoked, all branching INNE~ AN HENDER50N I
~ D~NNER I probabilitie8 ar~ ~et to FLOATING and ad~usted 30 that the 1300 I STflEET, N. ~V, I
~ASHIIJOTON. OC 2000 ,.20z40e~ooo -27-,1 2 ~
1 I branching probabilities for each workload add to 1Ø The ¦ FIXED probability attribute is used to indicate that a workload distribution should remained fixed for a given CPU, disk, or user group despite other changes that may af f ect certain workloads. Preferably, the branching probability is only fixed for the duration of a particular modeling session, and is not transferred into the .MDL file.
Workload parameters can al~o be set ~y using the S~T
Workload Parameters option for the display mode. If the SET
Workload Parame~ers option is chosen, a workload display 525, shown in Fi~ure 5(m), appears. Workload display 525 includes a list of workloads that have parameters which can ba modified. Once a workload is ~elected, ~uch as the Z-i FREQUENCY" workload shown in reverse text in di~play 525, the I workload parameters which can ba modified are displayed. A
i display 528 of tho~e workload parameters for workload Z-frequency is shown in Figure 5~n)~
AR iR apparent from di play 528, the workload parameters that can be changed in the preferred implementation include the transac~ion per ~econd (TPS) required by the associated ¦ workload, the numbers of instruction per ~econd (in j thou~and~) required by the workload, the number of I/Os per j tran~action ~or that workload, the ~ize of the I/O per I transaction, ~hown a~ di~k transfer sizs, for that workload, 1 and the number of locks per tran action. Locks are a .AwOrrcc~ ' cluster-wide synchronization mechanism to control acces~ to . INNEC~N, HENDERSOI`; I
FARABOW. GARRETT
~ DUNNER I common resourc~s.
1300 1 9TR~El', ~1. W.
WA5~ 5TOr~. OC Z000 1 20Z-.10~ 000 2 ~ 1l 7 C~
1 ¦ In addition, one can choose whether to indicate disk branching by SOURCE CPU. If the workload ha~ disk branching by SOURCE CPU, each CPU's I/O distribution depends on the CPU
running the workload. If not, there is common disk branching, and the I/O distribution across disks is the same regardless of which CPU is supporting the workload.
Th~ SET System Load option behaves in a similar manner.
If this option is chosen, a di~play 530 shown in Figure 5(o) ~ appears to allow an operator to change the load of the computer system either by workload, user group, or overall throughout the system. For example, one could double a particular workload, double the workload provided by a particular user group, or double the workload throughout the ! System.
` Once the SET System Load option and the manner of workload modification i~ cho~en, the operator i~ prompted to enter the parcentage load change and indicate whether the load is to be increased or decreased. After changing the ~ load, the SOhVE op~ion for the model mu~t be cho~en to 3ee I the effocts of the new load.
The SET Ob~ect Nc~me option can be used to change the name of an ob~ect. Ob~ects include model~, bu~ses (~uch as CI or NI), bus adapterc, CPU~, HSC~, channels, di~k~, ! workloads and user groups ~fter the SET Ob~ect Name op~ion " is selected, and ~he ob~ect i identified, the operator is ~wo~rlc~9 i prompted to supply the new ob~ect nc~me.
ECA~ HE~;DERSO~
hR.~3QW GARRETT
~D~ER
1~00 r 3Ta~r l, N. W.
lNOTON 3C 2000 I--Z02 40~ 000 ~ ' .
2~/~7 ï 3l :~
1, 1 ~ In a ~imilar manner, the SET Object Type option can be I used to change the type of bus adapter, CPU, H5C, or disk.
I If thi~ option is chosen, a display 533 shown in Figure 5(p) ! appears on keyboard/display 320 ~o indicate the device choices. Once a devlce is chosen, such as a disk in display 533 of Figure 5(p), a new submenu is overlaid indicating the different devices of the t~pe chosen. That submenu, shown as display 534 in Figure 5(q), show~ all the different disks in , the computer system.
When one or more of tha devices are chosen, then display 535 in Figure 5(r) is selected to indicate the pos~ible types of the ~elected device~. For example, in display 535 of Figure 5(r), the RA60 type of disk ha~ been selected.
In addition to s~tting workload distribution3 and system i parametexs, physical device3 can be added, deleted, or moved.
When the ADD option on the main menu 500 of Figure 5(a) is selected, then a display 540 shown in Figure 5(s) appears.
~he ADD option allows one to add a model, a bus (CI or NI), i an adapter, a CPU, an ~SC, a channel, a di3k, a workload, a user group, or MSCP ~erver information.
In display 540, the reverYe text indicates that a CPU
has been cho3en to be sdded. This caus~ the display 542 3hown in Figure 5(t) to appear on diYplay/keyboard 320.
Display 542 indicateR the different type3 of the CPUs which I can be added. In adding a CPU, an operator would al~o be .AWOr~cc, j a~ked to ~elec~ an adaptor by making a 3election from a INNEGAN, HENDER50N .
~ DUNNER I screen li8ti~g po88ible adapt~r~.
1300 ~ 9TR~T, N. W.
~'IAS~INOTON. I~C ZOOO~ j ,202~09-~000 _30_ ~ i ~v O .il ~
1 1 The manner in which the modeling interface determines i where to add the devic depends upon the type of device. For disk~, the operator is asked for the CPU or HSC channel to j receiving the di~k. CPUs, on ~he other hand, are added to the most recently identified bus and must be moved if necessary. This mechanism, however, is just the preferred implementation and is not required to practice this invention.
, If the DUPLICATE option is chosen from main menu 500 in Figure 5(a), a display 545 shown in Figure 5(u) appears. In the preferred implementation, the elements which can be duplicated include a model, a buq, an adapter, a CPU, an HSC, I a channel, a disk, a workload, a user group, or MSCP server ;i information. If ~he CPU option is chosen, as indicated by the reverse text in display 545, a display 547 as ~hown in Figure 5(v) appears on display/keyboard 320. Display 547 l indicate~ the possible CPUs which can be duplicated. The i device chosen is then duplicated. Both the chosen device and the duplicate device have the sams physical connections to `; the other device~.
To change a connection, the MOVE option in main menu 500 of Figure 5(a) i~ cho~en. If this option is chosen, display 550 ~hown in Figure 5(w) appears. The move option allow~ an , opera~or to move an adapter, a CPU, an HSC, a channel, a ,I disk, or a workload. If a disk is chosen ~o be moved, as ~AwOrrl~c~ !¦ shown by the reverse text in display 550, then a display 552, -INNEGAN. HENDERSON 1 8 D~NER I ¦ shown in Figure 5(x), appears.
1300 I STREET, N. W.
WA5111NOTON. OC 2000!1 1 202 -09 -000 ' .
~ f~ ~L r~ ~3 -/ J
1 1 Display 552 lists all the possible disks that can be I moved in the computer system. Using display 552, the operator chooses the disk, called the source disk, to be moved.
When moving a source disk, the CPU or the channel to which the source disk is to be moved mu~t be chosen. In the preferred implementation, this selection is accomplished using a display 553 shown in Figure 5(y), which appears on display/keyboard 320 after a disk is selected.
Display 553 indicate~ whether the disk is to be moved to a channel or to a CPU. In di~play 553, a CPU ha~ been chosen, as indicated by the reverse text. The selection o~ a CPU cau~es di~play 554, ~hown in Figure 5(z), to appear.
Display 554 list~ the po3sible CPU~ to which a di~k can be moved. A~ shown in display 5S4, ~he source disk is to be moved to a target CPU identified as CPU-7.
A physical device or workload can also be d~leted from the computer ~ystem configuration using the R~NOVE option in ' main menu 500 ~hown in Figure 5(a). Selection of this option cau~e~ the appearance of a di~play 555, ~hown in Figure 5~aa). Di~play 555 indicates the types of devices which can be r~movcd. Di~play 555 show~ that a CPU ha been chosen, which cause~ a display 557, shown in Figure 5(bb), to appear.
1 When a dsvice i~ to be removed, the opera~or i~ asked for a confirmation because removal of a device ha~ far-reaching ~worrlcc~ effect~ that are difficult to undo in the preferred INNECAN HEND~RSON, FARA~~ C~ERRR~T~ ' implementation. Al~o in the preferred implementation, 1300 I 9TFIEET, !1. W.
~VA9111~ T0~. OC Z0009 1 20Z ~0~'~000 1l --32--~ 7 ii `
1 removal of a device removes all devices connected to that device.
Returning to Figure 4 and flow chart 400, the next step I after receiving an input is the modifica~ion of the model of the compu~er system in accordance with received input to reflect the modified configuration of the computer system (step 430). Modification using the SET option uses the keyboard logic 323 and data storage 315. Modification using the ADD, DUPLICATE, MOVE, and RENOVE options uses changer 1 330. The details of how such modification occur~ in data storage 315 will be described in greater detail below.
If a change has been made which affect th~ distribution I of the workloads, the new workload distribu~ions must be I determined (step 440). The steps for redistributing are I shown in greater detail to the side of flow chart 400.
Redis~ributing involve~ identifying a set of physical ¦ device~ in the computer system to which the load will be redistributed. The device3 in the set are those which also support th~ workloadA as the identified physical device (i.e., I the one added or removed, or the one which had its workload altered) (step 443). For example, if a CPU had four disks and ona wa~ r~moved, the remaining three would constitute the set of physical devices involved in redistribution.
i The workload3 are then redistributed among the member~
of the set according to ~he ~alancing ~ode (step 447). ~his LAwO~rcc, redistribution requixe~ first determining which members of INNEGAI`;. HENDERSO~:
FARAsowGARRETT the set have FLOATING probabilities, and then distributing ~ DUNN~ER
1300 I STI:IEET, rl. W.
W~5il1NOTON. OC 2000~ ¦
~ 202-40~1 4000 1 _33_ ,1 'I
2 ~ 1 r~
1 I the probabilities among those members in accordance in the Balancing Mode Next, new values of the selected metrics for the I modified model of the computer system are determined (step ' 450). Preferably, this is accomplished by selecting the SOLVE option from main menu 500 shown in Figure 5(a).
After the new valu~ for the metrics are determined, the diagram of the modified configuration of the computer system, I with new values for the metrics, are displayed on display/
I keyboard 320 (step 460). The resulting displays have current information.
As example~, display 560 in Figure 5(cc) result from the addition of a CPU. Display 565 in Figure 5(dd) results from the movement of a disk. Display 570 in Figure 5(ee) results from the removal of a CPU. Display 575 in Figure 5(ff) results from the duplication of a CPU.
¦ Another feature provLded by the pre~erred implementation is the VIEW option which allow~ an operator to examine specific portions of a model. The view option permits a one ' level ZOON capability to ~how more detail. For sxample, if the VIEW option i~ chosen from main menu 500 in Figure 5(a), then ~ display 5R0 (Figure 5(gg)) appQars on display/keyboard 320 prompting the operator to indlcate which elements are , desired to be viewed.
If as indicated in display 580, a CPU is to be viewed, LAwO~rc~, then tha focu~ of the model i8 on the new CPU rather than on F I~NEG~; HEI~;DERSO~; .
FARI~SOW G~RRETT
~!1 Di,'~:~ER
laOO 1 5T~ T, N. \N.
OT~N, OC ZOOO~
,z0240g-4000 -34-I
~ O '1 7 ~
1 ¦ the entire model or some other de~ice. The display 582 in Figure 5(hh) then appaars.
Display 582 allows an operator to selec~ the CPUs in the I system to be viewed. If, as indicated in display 582 in ~ Figure S(hh), CPU-7 i5 chosen, then display 584 aq shown in Figure 5(ii) appears showing the CPU-7, it~ adapters, and the busseq to which it i~ connected in greater detail.
B. Data Structureq 1 Figure 6 is a block diagram of a model 600 showing the `¦ relationship between individual data s~ructure6 ~tored wi~hin ¦ da~a storage 315. The root of model 600 i9 the model roo~
610 which identifies a model for a computer sy~em created from the .MDL file and which is repre ented in a node deqcribed below. Model root 610 has five children, all of which interrelated, as described in detail below.
; Two of the children, the CI tree 620 and NI tres 630, ~ogether con~titute a device data ~tructure. Workload tree 640 is a data structure ~howing the relationships of the ,I different workloads to different devices. U~er group tree 1 650 i~ a data structure showing the differen~ user group~ and their relation~hip to different workloads. MSC~ tree 660 is a data structure ~howing the rela~ion~hips of device~
provlding ~SCP service~
, Although in the preferred embodiment, ~rees 620 660 have a modified treo da~a ~tructure, such a structure 1~ not ~wOrc~ ! strictly required to prac~ice the presant invention. As will -INNE(;AN HENDER50N ¦
F~R~BOW, G~RRErr 8 DUNNER I be apparent from the ds cription of the invention which 1300 1 9TREET, N. W.
W~9111N~3TON. OC ZOOO!S .
I Z02 .109-~000 .j Z ~ ll 7 ~ ~ ~
1 1 follow~, one advantage of a tree structure is the ease by which modification~ may be made to computer system configurations. Persons of ordinary skill in the art will recognize ~hat other data struc~ures which permit easy modification may also be used.
1. Device Data Structure.
An example of a CI tree 620 and an NI tree 630 are shown , in greater detail in Figure 7. In Figure 7, a device data i structure 100 is represented a~ including both a CI tree and 1 an NI tree. The particular configuration represented by j device data struc~ure 700 i~ that of computer system 100 I shown in figure 1.
¦ The CI tree 701 includes a CI root node 710 which has, ! as children, nodes for ~SC 140, represented by HSC node 720, l and adapters 112, and 123 for the CPUs coupled to CI bus 106 ¦ in Figure 1. Node 705 correspond~ to adapter 113, and node 706 corresponds to adapter 123. The child of adapter node , 705 i8 CPU1 node 730 corresponding ~o CPUl 110, and the child ¦ of adapter node 706 iR CPU2 node 740 corre~ponding to CPU2 1 120. The children of the HSC node 720 are channell 150, ! represented by channell node 721, and channel2 155, repres~nted by channel2 node 725.
Th~ children of channell node 721 are nodes representing I diskl 160 and disk2 162 (Figure 1). These node~ are diskl 1 node 722 and disk2 node 723, re~pec~ively. Similarly, the ~worrlcc~ ' child of channel2 node 725 is disk3 node 728, which 1!~;8;ECAN, HENDERSON ¦
FARA80W. CARRET~ , ~ D~N~R ' correspond~ to disk3 164 (Figure 1).
1300 1 9TRl!:Cr, N. W.
WAS~ OrO~`I. O C 20005 I 202 .0~1-4000 ;l -36 , .
I 2 0 ~ 7 ~ ~ ~
1 ` CPUl node 730 has a single child, disk4 node 735. Disk4 I node 735 corresponds to disk4 166 (Figure 1).
The NI tree 702 includes an NI root node 760 which has as children adapter nodes 707, 708, and 709, corresponding respectively to adapters 112, 122, and 132. The children of adapter nodes 707, 708, and 709 are respectively CPUl node 730, CPU2 node 740, and CPU3 node 750, corresponding respectively to CPU1 110, CPU2 120, and CPU3 130 (Figure 1).
I CPUl node 730 and CPU2 node 740 have already been described above in the discussion of CI tree 701. CPU3 nod~ 750 has ¦ two children, disk5 node 752 and disk6 node 753. Disk5 node 1 752 corresponds to disk5 168, and disk6 node 753 disk6 node ¦ 170, both in computer system 100 ~Figure 1).
¦ Device data ~tructure 700 include~ node~ each of which I correspond to a different physical device of the computer ¦ system represented. Fi~ure 8 shows a diagram of a preferred implementation of a generic node 800. The node is called generic because it can be used, with slight modification, as I a node for model root 610 or any of the trees 620-660 shown in Figure 6. Node 800 has ~everal fields 810-860.
Name field 810 contain3 tho name of the element represented by the node. The contents of name fiald i~
preferably a string.
Statistics record list head 820 for a device.identifies i the location of a linked list of stati tics element~ 821 each ~worrlcc~ ¦ of which contain3 certain stati~tic~ for a workload ~upported INNEC~N HE~;DERSO1~; ~
~D~ R l by the devic~. For a d~vice, stati3tic3 record 821 includes 1300 I STi~CET, N. W.
W~3~1NOTON. OC 2000~5 1'202'40el 4000 1 37 . ' 1 1~ a rate ~ubfield 822 indicating the number of processing tran~actions (TPS) or I/O tran~actions (I/Os) from the device for the corresponding worXload. Queue length subfield 823 indicates the length of the queue that is waiting to use the device for the corresponding workload. Service time subfield 824 indicates the amount of time that takes the device to process a request for the corresponding workload. Response time ~ubfield 825 equal~ the service time plus any queuing I delays. Utilization subfield 82b indicate~ the percentage of I the devices capabilities currently being utilized for the corresponding wor~load. Workload pointer 827 indicates the node for the corre~ponding workload.
I In addition, there is an additional statistics element ¦ in the linked list. Thi~ element has the compo~ite l ~tati~tics for all o the workloads of the device.
The stati~tic~ t head for workload nodes has entries for rate field 822 indicating the throughput for the entire workload, and for re~pon3e time ~ubfield 825, which I represents the time to complete an entirs transaction for I that workload. The workload pointer subfield 827 indicate~
the model node.
, All of ~he ~ubfieldR in ~tatistics record 821 are repre~ented as real number~, except for the workload pointer, and ~he values in all of the field3 except the rate field are I de~ermined a~ a rasult of performing ths SOLVE option. ~he .AwO~r~ccg jl value in the rate field i5 either input by a usar, or i~
I:~NECAN. HENDERSON ~ I
FARA80W~ GARRETT
~D~ ER ! received from tha .NDL fLle.
1300 1 9TPEET. N. V,l. I
5r~1~0TON. 0C 2000 I ZOZ 40~ 4000 1 1 The library pointer suhfield 830 of generic node 800 , references a library record specific to a device type. The library record describes parameters associa~ed with that I device type. For example, the library for a certain type of disk would contain its seek time, latency, transfer rate, etc.
Link array field 840 identifiei headers for various linked li~ts which relate to the element corresponding to I node 800. One set of headers i5 shown in detail in Figure 9 ~ as link header list 900. Link header list 900 include~ a workload linked list header 910, a paren~ linked list header j 920, a child linked list header 930, and an MSCP linked list i header 940.
l Workload linked li~it header 940 i~ a header for a linked ~ list of workloads which the corresponding device support4.
Parent linked list header 920 i~ the header for a linked list of nodes which are parents to the corresponding element node.
In a ~imilar manner, child linked list header 930 is the header for a linked lis~ of the children of the corre~pondlng ~0 element. MSCP linked list header 940 i~ the he~der for a linked li3t of MSCP tress involving the device corresponding to the node. In the preferred emhodiment, tha link header I list, and mors cpecifically the linked list~i, are specific to the different types of nodes.
Figure 10 shows an example of a linked li~t 1000 which .AwOrr,c., I can be u~ied as any of the linked list3 de~cribed above. In INNECAN. HENDER50N ~
FAR.~90W. GARRETT Figure 10, the linked li8t 1000 includ~s a list head typa ~ :~00 ! 3TR~rT, N. W. l WASl-llNaTON. OC 20003;
1 202' 4013-~000 . - 39-2, ~
1 1 1005 and link elements. List head type 1005 in turn includes a forward link 1030, a backwards link 1060, and a count 1080.
Forward link 1030 indicates the location of the first element ' in linked list 1000, backward link 1060 indicates the location of the last element in linked list 1000, and count 1080 indicates the number of elements in linked list 1000.
Linked list 1000 i~ called a doubly-linked list because it is linked in the forward direction ~hrough the forward I links 1013 and 1023~ and in the backwards direction through , backward links 1025 and 1015. Note that the la~t link element, element 1020, ha~ a forward link 10~3 to a nil i record 1095, and the first link element 1010 has a backward j link 1015 to a nil element 1090.
I Linked list element 1010 ha~ pointer 1018 which 1 identifies a corresponding node, and linked li~t element 1020 has a pointer 1028 to a corresponding node 1029.
Returning to generic node 800 in Figure 8, subfield 850 indicates the type of nod~. The different node type5 include , model type~, device types, worXload typas, branching types, ¦ u~er group types, and MSCP typa~.
! Associated with many of the type.~ of nodes is a variant record 860 which contain~ information unique to different ¦ node types. One example of a variant record i~ variant ¦ record 1100 shown in Figure ll(a) for a model node. It i includes as cubfield~ a device li~ pointer 1110, a selection ~wor~l~c~ j device pointer 1112, a configuration field 1114 defining the !NNECAN. HeNDER50N: ¦
FARABOW. G~RRET~
~) 3UI`;NER .
1~00 I gTRl!:~T, N Vl.
W~INOTON. OC ZOOO~
~Z02 0~1 AOOO
, 40-:, ~ ~ ~ 7 ! r 1 1 particular ~onfigu~ation type of the model, a modified flag 1116, and a solved flag 1118.
Figure ll(b) shows a model node 1130 including the ¦ variable record portion. The name field 1132 contains the name of the correspondin~ model. The statistic~ list head field 1134 and the library pointer field 1136 are empty.
The link array 1140 only has entries for the child linked list with header 1142. In the preferred embodiment ~I for model node 610, the linked list for header 1142 would j identify a list with nodes for the CI node 710 and the NI
node 760.
Élement type field 1145 identifies node 1130 as a model.
~ Select device pointer 1150 point~ to a list of items ! identifyin~ either a current model 1152, a current device, ¦ such as the entry for the current CI bus 1154, or a current ¦ workload ~not shown)~ The row and column entries identify j the location of ~he corresponding model, de~ice, or workload ¦ on the screen of display/kayboard 320.
¦ Device list pointer 1160 identifies list header for each of the compone~t~ of the corresponding model. Model list head 1162 i~ for a ~ingla element iden~ifying the model node.
CI li~t head 116~ i~ for a list 1170 of CI linked list ele~ent 1172 and 1174. Li~ts would al o exi~t for CPUs, l HSC~, di~k3, etc. Li~t 1170 indicates that the model , corresponding to node 1130 includes two CI busse~.
~worrlccg Configuration field 1180 iden~ifie~ the configuration of lI`i'NECAN, HE:`iDER50N . ¦ .
8 ~NNER i the corresponding model. A model can hav~ 3e~ral different 1300 ~ STFIE:~, N. w.
W~91~1N'3TON. OC 2000~, 202 40a-4000 41--!l I
~ .3 1 ~ configurations. Model 600, for example, is a mixed cluster configuration, another example of which is shown in Figure 12(a). Figure 12(b) shows a standalone configuration.
i Figure 12(c) shows a CI cluster, and Figure 12(d) shows an NI
cluster.
Modified flag 1190 indicates whether the model has been modified. Solved flag 1195 indicates whether the model has been solved (i.e., whether the SOLVE option has been invoked) after all the changes have been made. Modified flag 1190 and solved flag 1195 are Boolean values and together indicate whether any data is stale and should be displayed in bold text.
Figure 13 shows another example o a variant record, variant record 1300 for a device. Record 1300 includes an i MSCP pointer 1310 which identifie~ a corre~ponding MSCP tree if the device is a CPU or a disk.
I 2. Workload Data Structure.
¦ Also in accordance with the present invention, a I workload data structure includes a plurality of second data 1 entries each corre~ponding to a differ2nt one of the , workloads which the computer sy~tem support~. In the preferrod embodiment, the workload data structure i~ al~o a tree.
Figure 14 includes a workload tree 1400 for workload 1, and shows its relationship to a portion of a device tree .A_Orrc~ I 1401. That relationship i by way of branching IECA~;. HE~DER30t; . ¦
8 D~ER ! probabilities.
130Q I sn~ccr, N. W.
W~5~11NOTON. DC Z0005 ~ Z02 ' ~0 1 ' 4000 --42--I
2 n ~
1 1 The portion of the device data tree 1401 shown in Figure 14 includes CPU nodes 1455, 1460, and 1465 for CPU1, CPU2, and CPU3, respectively. CPUl node 1455 has as children three l disk nodes, diskl node 1475, disk2 node 1480 and disk3 node ' 1485.
Workload tree 1400 includes a workload root node 1405, I which has as children workload-l node 1410, workload2 node ¦ 1412, and workload3 node 1414. Workloadl node 1~10 has a~
j children a CPU branching probability node 1420 for CPUl, a ¦ CPU branching probability node 1422 for CPU2, and a CPU
I branching probability node 1424 for CPU3- This ~truc~ure ¦ mirrors the structure for device tree 1401.
CPU branching probability node 1420 has three nodes a~
children: diskl branching probability node 1481, disk2 branching probability node 1482, and disk3 branching probability node 1483, which correspond to di k node~ 1475, ¦ 1480, and 1485, re~pectively. This ~tructure al~o mirror~
the structure for device tree 1401.
CPUl noda 1455 is related to workloadl by branching 1 probability noda 1420. CPU2 node 1460 is related to I workloadl by branching probability node 1422, CPU3 node 1465 i8 related to workloadl by branching probability node 1424.
AB explained above, the branching probability for a corre~ponding device and workload is an indication of what percentage of th~ corresponding workload has services .AwOrrlc~, ~ provided by tha corresponding device. Thu~, aR represented INNEG,~N HENDER50N .
~ D~;NNER ; by branching probability nod~s 1420, 1422 and 1424, workloadl 1300 ~ 9TREET, N W.
W~9~11NGTON. DC 2000~
1'202 .~0~'~000 -43-2 0 '~
1 ! ha~ 80~ of its cpu 3ervices provided by CPUl, 5~ of its CPU
service3 provided by CPU2, and 15% of its CPU services provided by CPU3. The percentages in the branching I probabilitie~O must add to 100~.
The branching probabilities for the disks also add to 1 100%, although it should be understood that the percentages ¦ represented by the branching probabilities of nodes 1481, 1482 and 1483 represent only the percentage of the disk ' services which are provided for the portion of workloadl supported by CPUl. For example, the branchLng probability ¦ for workloadl provided by diskl is 30%, the branching I probability for workloadl provided by di~k2 iY 40%, and the .I branching probability for workload3 provided disk3 i~ 30~, ¦ but these are percentages of the workloadl ~ervice~ provided by CPUl. To determine the total amount of system resources : which diskl provides for workloadl, the branching probability ; for di~kl, 30~, ha~ to be multiplied by the branching . probability for CPUl, 80%. In this case, the re~ult of such ~I multiplication would yield 24%, indicating that di~kl provides 24% of the disk re ource~ required by workloadl.
! The workload data node ha~ the basic ~truc~ure of the generic node 800, except the library point~r 830 i~ not u~ed, and the linked list field does not include an MSCP linked . li~t 940. The variant reco~d portion for a workload node is ¦ shown in Figuro 15 as record 1500. The information provided ~worrlcc~ ¦ in the workload variant r~cord 1500 include~ the re~uired 8 D~;NNER txan~action~ per second provided in Hubfi~ld 1510, the 1300 1 9T~ El'. N. W.
W~ 3TON. ~C 2000 ~ C02 0- 0~0 _44_ 2 0 '~ 7 '~ J ~
1 1 required instructions per second provided in subfield 1520, the required disk I~Os provided in subfield 1530, and the required I/O size, provided in subfield 1540. In addition, ¦ workload variant record 1500 includes a lock subfield 1550 ~ which is the lock explained above, and a BY SOURCE field 1560 which was also explained above. All of the fields in variant record 1500 are real, except for BY SOURCE field 1560 which i~ Boolean.
I The branching probability node~ are al~o similar to the ~i, generic node 800, except they do not include a name field, a statistics list head 820, a library pointer 830, and element type field 850 and there is no workload linked li~t 910 or i MSCP linked li~t 940. ~he variant record for a branching I probability node i8 ~hown in Figure 16 aS~ record 1600.
, Record 1600 includes four ~ubfields. Float Stubfield 1610 contains a Boolean value indicating whether the branching I probability i~ FLOATING or FIXED, as explained above.
¦ Probability ~ub~ield lS20 contains ~ha corresponding Il branching probability. Norkload point~r stubield 1630 1l identifie4 the node for workload corresponding to this branching probability, and device pointer subfield 1640 identi~iQs tha nod3 for the corre~ponding device.
Fi~Are 17 i~ a diagram 1700 ~howing the l interrelationship betw~an various nodes for device and i workload treas. Diagram 1700 al~o indicates the field~ of .AwOrrc~, ~ each node which are actlve for the corre~ponding node.
-INNE~;~N. HE!`:DRSO~`;, hRA30~. CARRETT
9 D~NER
1~00 t ST~lU:r, N. W.
~IIN0TON~ 0C 20005;
1`202 40:~ -000 , -45-2 ~ ll 7 ~ I ~
.1 1 ¦ CPU device node 1710 includes a name field 1711, a library pointer 1712, a statistics list head 1713, and an elemen~ type field 1717. Pointers 1714-1716 are part of a link array. Workload pointer 1714 identifies a workload linked li~t of branching probability node~; parent pointer 1715 iden~ifies a linked list of nodes for the parents of CPU
device node 1710; and child pointer 1716 identifies a linked li t of nodes for the children of CPU device node 1710.
As Figura 17 shows, one of the children in the linked list which pointer 1716 identifie~ is a disk device node 1720. Disk device node 1720 represents a disk connected to the CPU represented by CPU node 1710.
Disk device node 1720 include~ a name field 1721, a library pointer 1722, a sta~i~tic~ t head 1723, and an element type field 1726. As part of its link arxay subfields, disk device node 1720 include~ a worklo~d pointer-to a linked list of branch probability nodas, and a parent pointer identifying a linked li3t of nodeR for parents of disk device node 1720. The parent linked list includes CPU
device node 1710. Disk node 1720 has no children ob~ects and i therefore ha~ an empty children linked list o~ child node-~.
¦ The branch pointer 1714 of CPU device node 1710 .¦ identifies a CPU branch probability node 1730 for the I worklo~d repre~en~ed by workload node 1750. CPU branch I probability node 1730 include a parent poin~er 1732, which ~wo,rlcc, I identifie~ workload noda 1750, and a child pointer 1733, EG~N. HE~DER501~; 1 FARA30W C~RRETT
~ DUN~ER ::
1300 ~ STQEET, N. V~.
W~N3TON. I:)C ZOOOS
I~Z02 40~-~000 2 ~ 4 7 ~ ~ ~
1 ~ which identifies a linked li3t containing the disk branch probability node 1740.
The CPU branch probability node 1730 also includes a ' float field 1734, a probability field 1735 containing the branch probability valuel and a type field 1738. ~orkload pointer field 1736 identifies workload node 1750, and device pointer field 1737 identifies CPU device node 1710.
The disk branch probability node 1740 is similar in content to the CPU branch probability node 1730, excep~ that disk branch probability node 1740 does not contain a linked : list for the children nodes. Parent pointer 1742 identifies CPU branch probability node 1730.
Workload pointer 1746 identifie~ the workload node 1750 ~ for the correspondin~ workload, and the device pointer 1747 lS l identifies the di~k devico node 1720 for the corre3ponding disk. DiRk probability node 1740 al o contains a float field 1744, a probability field 1745, and an element type field 1748.
.' The worklo`ad node 1750 contains an entry in the name , field 1752, as wall a~ entries for statistics list head 1753, parent pointer 17S5, and child pointer 1756. Parent pointer 17S5 identifies the model node, and child pointer 1756 , identifi~s a linked li~t with CPU branch probability node 1730 and a u~er group branch probability node 178p.
~¦ Workload node 1750 also contains entries for the L~wOr~lc~ ~! transactions per ~econd field 1757, tha instruction per INNE(;AN. HENDER501`; . ¦
~DuNNER , ~econd fi~ld 1758, th~ di~k I/Os fi~ld 1759, the I/O size 1300 1 9TR~ET. N. V~.
~V~3~11NOTON. DC 20003 I 202 ~oel-~000 ~ -~7-I1 2~ll7~
1 field 1760, the lock field 1761, the BY SOURCE field 1762, and the element type field 1763.
; The present inven~ion relates to the field of automatic performance analysis and capacity planning and, more specifically, to the field of au~omatic performance analysis and capacity planning of computer sy~tems which have been modified in response to interactive operator input.
Performance analy~iq in computer systems is used to determine the effectiveness and efficiency of a computer ' system~s management of its workloads. The term ~'workload"
, refers to processes running on a computer system. Different types of processes are often treated as different workloads.
For example, word processing iq oft~n con3idered as one workload even though several computer sy~tem users are ~1 operating word processing program~. Similarly, ~preadsheets , could be considered a a distinct workload.
Each workload requires system re~ources, such as CPU
(central proce~sing unit) proco~sing time or disk capacity.
I' Performance analysis is designed to facilitate the management i! f such sy~tem resource~.
1l In carrying out performance analy~ls, one must always measure 30mo values for computer system and component ¦ par~meter~ in order to determine efficiency and efficacy.
The parameter~ being mea~ured have been referred to as ~ metric~ Example~ of metrics are ~he number of cache 2~wor~ misses in a particular time period, the number of page faul~s EC~ H ~DER~O~;; I
hR~30~' G~RR'rT ~ I
~D~ ER ;j in a particular time period, or the length of a device's ~00 ~ ~--R~ IV~ ~V
NI:ITON. OC 20005 ~O~O~.OOO -2-1.l 2.~1~7~ ! ~
1 j queue. Metrics are discusRed more fully in U.S. Patent No.
4,849,879 to Chinnaswam~ ~t al., which is incorporated herein by reference.
The metrics reflect the performance of the comp~Ater I system in a particular configuration. The term ~configuration~ used to refer not only to the types and interconnection of physical components, but also to the distribution of the workloads among the components.
I Most conventional methods of performance analysis and capacity planning involve presenting selected information in reports. The reports are usually tabular presentations of ,I data. Usually ~everal different kinds of reports are needed il for analysi~. For example, one rsport might indicate ~he ~¦ system configuration in term~ of component~, another report i~ might indica~e the system configuration in term~ of workload, 'I and another report may list certain metrics of interest.
il One performance analysis and capacity planning product which generate abular reports i~ the DECcp or DEC Capacity II Planner for V~S made av~ilable by DLgital Equipment i Corporation for u8e with certain VAX computers. This product l collects, reduces, analyzes, models and reports data in a ! tabular format for purposes of computer system capacity l planning. Another ~uch product i3 the VAX Performance I Advisor made available by Digital Equipment Corporation to 1 provide information u~eful in analyzing the performance of ~Aworrcc~ l certain VAX computers.
. INNEG~N, HENDER30~
F.'~RA30W G~RRETT ,:
~I DE'~i~lER j 1:~00 I ST~II:F;'. N W.
W~S~ GTON. DC ZOOO~ ~ j 1' 2~02 '10~ ~OOO , j _ 3_ r-7 ~
1 1 Although the tabular presentation of data may beacceptable ~or determining the performance of a computer system in one configuration, it does not lend itself well to analy~ing the performance of the computer system if its configuration were modified. Such analysi~ is importan~ in determining whether and how to reconfigure a system.
For example, if performance analysis indicated an overload or bottleneck condition in a computer system, the I system should be tuned or reconfigured to alleviate such i conditions. It is not always apparent, however, which tuning or reconfiguration is th~ most appropriate. Physical reconfiguration of a system without knowing whether that reconfiguration will be effectiva is both impractical and 1'1 costly.
11 To avoid unnecessary or incorrect reconfiguration, system engineer~ try to con~truct a model based upon actual system parameters. In this way, modeling may be us~d to I measure the impact of certain actions on system performance '1¦ before physically reconfiguring a computor i3ystem.
1 Modeling can al80 be uised in i3alois. If a modeling technique were not too cumberi~ome~ salespeople could use it to determins whether additional components were needed for a il particular cu3tomor, or whether a customer' 8 problemis or l needs could be handled in other way8.
1 Convantional performanca analy~is sys~ems, howev2r, do ~w or~c~ ! not lend themselvei~ well to such ui3eR A common means of FINNEC'.N~ HE~;DERSO~
F~R~aD~;N~NERRRE~ 1~I performing modeling involves using the information gathered ~000 1 9T~ECr, N~ W. j j w~.glll~0TON. OC 2000~ ~
,z02~00.000 ,, ~4 'i ,~ 5 ~ `
1 1¦ as part of the performancs analysis to calculate th~ effect of roconfiguring a computer sy~tem. This i~ both time con~uming and inaccurate.
Systems such as the DECcp system will perform certain automated calculations, however, the calculations are presented in a tabular format, which may again require the use of several sheets or tables to analyze results.
therefore deqirable to provide a mechanism for I performance analysi~ that allows for a more meaningful ' presentation of performance information.
Another desire is to provide an improved mechanism for changing the configurations of the computer sy~em, at least in a virtual ~ense, to determine the effect~ of such changes.
', An additional de~ire would bo to provide an improved lS i mechanism for pre~enting the effects of the changes in; configuration in a manner which allows ready deci~ion making.
Additional advantages of this invention will be set , forth in part ln ths de~cription which follows and in part ¦ will be obvious from that description, or may be learned by I practice of this invention. The advantages of this invention ¦ may be realized and atta~ned by means of the ¦ instrumentalitiQs and combinations particularly pointed in ¦~ th~ aPp9nded claim8.
,1 ,¦ II. S~NaR~ OF TH~ INVEFTIO~
~ orrlc- i! To achieve the ob~ects and in accordanco with the 'EC~I, tlE~lDERsO~; I
~9D~;~G~ER~ETT ' purpose of the invention, a~ embodied and broadly described ~00 1 ~Q~Er. Y. ~.
3r~YOTOY :~C 2000~ ~
1`:02`40~ 000 ' _5_ ., , ~'i7~ j 1 ll herein, the present invention provides a display of a jl computer ~ystem's configuration along with selected system metric~. An operator can change the configuration by using the display. Metrics represen~ative of the performance of the computer system would then be determined for the changed configuration, and could be presented along with the display of the new sy~tem configuration.
More particularly, a method of evaluating the performance of a computer system described by a configuration ` representing physical devices, the connections of the physical devices in the computer system, and workloads which . are processes that use iystem resources provided by the physical devices, comprises the step~i, executed by a modeling ~ data proce3sor, of: creatirAg a model of the configuration of I the computer system in the modeling data proce~isor;
displaying, on a visual display device coupled to the data processor, a diagram of the configuration of the computer system; receiving an input to modify the configuration of the ` computer system; modifying the model of the computer system in response to tha received input to reflect the modifiod 1~ configuration of the computer system; determining new values !¦ of selected metrics for the modified model of the computer ~ y~tem, metrics includlng mea~urable values repre~entative of il th~ performance of the computer system; and displaying on ~he ~1 visual display devlce a diagram of the modified configuration .AwOrrc~g 1, of the computer system.
INNE~AN HENDER'jON ~ ¦
FARA90W. GARRETT
h DUNNER j ' 1300 ~ 9TREET, ~.1. W. , j W~lliOTOrl. I:IC 2000!S
1 202.40a-4000 ~ -6--1 .1 A data structure, according to the present invention, I for use in modeling a computer system con~aining a plurality of physical devices supporting a plurality of workloads resides in a modeling data processor and comprises a plurality of first data entries organized into an easily modifiable first data structure, each of the first data entries corresponding to a different physical device of the computer sy~tem, and a plurality of second daT~a en~ries ~' organized into an easily modifiable sacond data structure, each of the second entries corresponding to one of the workloads which the devices in the computer system support by supplying system resourcss to the workloads. The first entries include device identification means for identifying .j the corresponding physical device, and device data structure , means for indica~ing a hierarchical relationship in the computer system configuration of the corresponding device ` with selected other ones of the phy~ical devices. The second .` entrie~ each include workload pointer means for identifying , the corresponding workload, device pointer means for ~ associating the corresponding workload with the one~ of the ji devices supportinq the corresponding workload, and j probability mean2~ for quantifying the system resource ''i supplied to the corresponding workload by the associated one Il of the phy4ical devices.
j Additionally, a modeling system of thi~ invention for '^w or~.Cc~ i facilitating analy~is of a computer sy~tem comprise3: data ;EC~. HE~DE.~O~; j ~R~DW~ E~RRETr ' structure means for holding physical device information and 1300 ~ g~ W
w~ 0~0~. DC 20003 I`:02 '10~ 000 ~7L`t` :~`
1 1 workload information, both representative of the configuration of the computer system, and metrics information representative of the performance of the computer system;
I change means, coupled to the data structure means, for receiving requests to modify the physical device information;
!; solv~r means, coupled to the data structure means, for determining value~ for metrics information for the computer system from the physical device information and the workload information in the data structure means; and user interface 1l means, coupled to the change means and to the data structure means, for providing an interface to a user o~ the modeling Il system. The data structure means includes configuration ¦¦ context means for storing the phy~ical configuration informa-il tion and the workload information. The changer means lS l! includes data structure modification mean3 for transmitting to the data structure mean~, in respons~ to the received Il request~, commands to modify the representation of the Il computer sy3tem configuration. The user interface means !! include~ means for tran~mitting to the change means the requests to modify the phy~ical device information made by a u~er, and means for displaying a ~iagram of the configuration of the computer system, including value~ for the metrics ! information.
, III. BRIEE' DESCRIPTION OF THE DRAWINGS
, The accompanying drawing3, which are incorporated in and ~WO~ constitute a part of this specLfication illus~rate EC~; HE~DER5~: 1 ..~R.~B~W ~RRETT , ~mbOdiment8 of the inv~ntion and, togethar with the '300 ~ ST~667. N. W
W~9~1~N0701'J. DC 2000~ .!
1-20240d-4000 i! -8-!!
!l r f 1 1I description, ~erve to explain the ob~ects, advantages and 1l¦ principles of the invention. In the drawingq:
~I Figure 1 is a diagram of a computer system that can be modeled in accordance with the present invention;
Figure 2 is a display of the computer system in Figure 1 generated by a modeling interface of the present invention;
Figure 3 (a) is a diagram of one preferred implementation of the modeling interface of this invention;
Figure 3 (b) is a diagram Ol' another preferred implementation of the modeling interface of thi~ invention;
Figure 4 is a flow diagram of the gsneral operations in a preferred implementation of this invention;
Figures S (a) through 5(ii) are screen displays Il generated during the operation of the preferxed 1 implementation of the modeling interface of this invention;
j Figure 6 is an overview of the data structure used in the preferxed implementation of this invention;
Figure 7 is a diagram of a preferred implementation of a 1 device tree;
!I Fiqure 8 i~ a diagr~m of a prefarred implementation of a li ~eneric node for use in the data struCturQ of Figure 6;
Figure 9 is a preferred implemen~ation of a link array for u~e in the node of Figure 8;
1, Figure lO is a diagram of a linkage list represen~ed by ¦, the link array in Figure 9;
~ wo~r~cc~ li Figure ll(a) is a diagram of variant record for a model -INNECAN HENDERSO1~; I
FARAaOW GARRETT d 6 DUNNER I no e;
1300 t ST~EeT, N. W.
W~3~1t.15T0~.1. DC Z000~ j ' I 202 401~- ~000 li Il il 1 ' Fi~ure ll(b) is a diagram of an exemplary model node in l accordance with the present invention;
1 Figures 12(a) - 12(d) are examples of different model ,I configurations;
Figure 13 is a diagram of the variant record for a device node;
Figurs 14 is a diagram of a workload data tree showing ~1 its relationship to a device tree.
.l Figure 15 is a diagram of a variant record portion of a ,l workload node;
,I Figure 16 is a diagram of branch probability node;
¦¦ Figure 17 i~ a diagram ~howing relationship between nodes of device tree, a workload trQe and a user group tree, li~ Figuxe 18 i~ a diagram of u~er group data tree;
ll Figure 19 i~ a diagram of computer ~ystem using MSCP
jl feature;
,i Figure 20 is a diagram of an MSCP data tree;
,~ Figure 21 i~ a diagram showing the relationship between j MSCP data trees and a d~vice tree;
1¦ Figure 22 diagram of the variant record portion of an ¦ MSCP node;
Figure 23 i~ a diagram showin~ the relatlonship of portions of device tree nodes and MSCP tree nodes;
i Figure 24 include~ a generalized flow diagram 2400 1l explaining how this invention reacts to inputs from ,~w orrlc~- , ! operator~;
INNEG~N. HENDERSON j !
F.~RA80W. GAR RETT , ¦
~ DUNNER ¦ I
~300 1 5TQEET. N. W. ! j W~IN'3TON, I~C 2000!S
I~Z02~00~-000 ~ 0--I!
1 Figure 25 includes a flow diagram for the preferred i implementation of the FILE procedure shown in Figure 24;
Figures 26(a) and 26(b) include a flow diagram for the , preferred implementation of the SET proce~ure shown in Figure 24;
Figure 27 includes a flow diagram for the preferred implementation OL' the ADD procedure shown in Figure 24;
Figure 28 include~ a flow diagram for the pref~rred , implementation of the DUPLICATE procedure shown in Figure 24;
Figure 29 include~ a flow diagr~m for the preferred implementation of the MOVE procedure shown in Figure 24;
I Figure 30 is a diagram for explaining how the loads are " distributed according to the preferred implementation of the Il MOVE procedure in Figure 29, I Figures 31(a), 31(b), and 31~c) include a flow diagram 'I for the preferred implementation of the REMOVE procedure !I shown in Figure 24;
I; Figure 32 includes a flow diagram for the preerred I¦ implementation of the VIEW procedure shown in Figure 24;
ll Figure 33 includeQ a flow diasram for the preferred il implementation of the SOLVE proc~dure ~hown in Figure 24; and I¦ Figure 34 ~hows a forma~ for certain files with which ! il the par~e~ interface.
¦I rv. DESCRIPTION OP T~ P~F~RR~D r4P~E~TATI~
~I Reference will now be made in de~ail to the con~truction .AwOrrlcc~ ,~ and operation of preferred implementation of the present EGAt~: HE~:DER30~ l;
FARA30W. GARRETT ~ !
~D~ER ~, invention which are illu~trated in the accompanying drawings.
1300 ~ ST~EET, N. W.
w~5~1~10T0!1. DC 20005 ' ~ ZOZ .~09 .-000 !
!l 1 il In tho~e drawinqs, like elements and operations are de~ignated with the same reference characters.
! In the following description, the preferred ,l implementations described are examples of the present , invention. The present invention, however, is not limited to ' these examples, but may bt~ realized in other implementations.
A. SYstem Desian and OPeration 1. Com~uter svstem beinq modeled Figure 1 shows a diagram of a computer sy~tem 100 which I can be modeled and analyzed in accordance with the present invention. It should be understood tha~ computer system 100 Il is merely exemplary, and use of the pre~tent invention i~ not - limited to any particular computer syttem configuration.
ll System 100 contain~ two bu~se~, NI bu~ 103 and CI buT
1 106. NI bus 103 is profarably an Ethernet-type bus for high speed data communication among a pluxality of network nodes.
CI bus 106 is preferably a bu~ used to connect devices in a ,¦ cluster configuration. The details of a CI bus are de~cribed ,¦ in U.S. Patent No. 4,560,985 to StrecXer, st al.
1l Coupled to CI bu~ 106 and NI bu~ 103 axe CPUl 110, CPU2 l 120, snd CPU3 130. CPUl 110 has a bus interface 112 for i connect~on to NI bus 103, and a bus interface 113 for ¦¦ connection to CI bus 106. CPU2 120 hact a bus interface 122 I¦ for connection to NI bus 103 and a bu~ interface 123 for 1¦ connection to with CI bu~ 106. CPU3 130 ha~ a bus interface .Aworrlcc3 , 132 for connection to MI bu3 103.
EC~N~ HE~DERSO~;;
FARA30~. C~RRETT
8 D~ ER
1~00 t 9T~tEET N. W.
W~lNOTON~ 3C 20009 ,z02.0~000 ll -12-!
I1 2~7~ ;~
1 I HSC (hierarchical storage controller) 140 manages communication~ between disks and CI bus 106. HSC 140 ! includes two channels, channell 150 and channel2 155, each of which is connected to one or more disks. Channell 150 is connected to disks Dl 160 and disk D2 162. Channel2 155 is connected to disk D3 164.
In system 100, disk D4 166 is connected to CPUl 1 110.
Disk D5 168 and disk D6 170 are both connected to CPU3 130.
Figure 2 shows a computer generated display 200 of the computer system 100 shown in Figure 1. Display 200 in Figure 2 is generated on a modeling data processor. The modeling ` data processor can be one of the CPU~ in computer sy~tem 100, but need not be. The purpo~e of the modeling data processor l is to implement the processes nece~sary for performance 1 analysis and capacity planning in accordance with the present invention.
" Display 200 not only includes all of the busses, CPUs, HSCs, channel~, and disk~ of ~y~tem 100, but also includes Il information such as the ~ype of CPUs and HSC, and an identification of at lea~t one workload. As explained above, wor~loads are processas that use ~ystem resources.
!~ Associated with aach workload i~ one or more device branching probabilities. For each workload, there i~ a Ii branching probability associated with every de~ice that 2S `, provide~ sy3tem resource~ for ~or 3upports) that workload.
.~wO~cc~ -! The device branching probabillty ~or a workload and a device EC~I HE~DERSO~; ~
F~R8DW~;~G~ERRRETr ¦ representg the percentage or fraction of the system resources 1~00 I ST~ E T, N. w.
W/~irllNOT~-I. DC 2000~ !
202 40~' ~ ll -13-'i ~ O ~ 7 ~
, required by a workload that is supported by the corresponding device. For example, if C2U1 has a branching probability of 20% for workload 1, then 20% of the CPU processing resources ` required by workload 1 are supplied by CPUl 110.
I Two other concepts which are important to understand, but which are not shown in Figures 1 or 2, are user groups and MSCP protocols. A user group is a set of user~ which are organized together for some purpose, such as management. A
user group's workload i~ the ~um of the workloads created by I the individual user in the user group.
User groups al~o have branching probabilities for I workloads to which those user group~ contribute. U~er group 'i branching probabilities reflect the percentage or fraction of i each workload which i9 created by the corrssponding user group.
The MSCP, or mass ~torage communications pro~ocol, i~ a protocol which allows a process executing on one CPU to Ij accesq files on disks not connected to that CPU in a manner ij~ which i3 in~i~ible to the proce3s. A more detailed 1 description of tho MSCP can be found in U.S. Patent No.
¦l 4,449,182 to ~ubinson, et al.
¦I The modeling interface of the present invention ¦l acco~modate~ these and other concept~ and provides Il interactive cemputer ~ys~em modeling for performance analysis 11 and capacity planning. In accordance with thi~ invention, AwO~rc~ operator~ can view a represen~ation of a computer ~ystem INNEC~N HENDERSON I;
FARABO~'. ~ARRETT
~ D~NNER Ij configuration and then designate change to that 1300 ~ STREET, N. W. j I
WA91-UNGTON. DC ZOOO!I ¦
1 202-~100 -000 j !
ll 2 o ll 7 ~
1 jj configuration, such a~ the a~dition, removal, or ¦ reconfiguration of devices or workloa~s. The results of tho~e changes would then be determined and pre~ented 50 an operator can view the results.
Furthermore, the modeling and analysi~ can be performed according to user groups and can take in~o accoun~ the use of `I MSCP services. As the preferred implementations demonstrate, the present invention also allowq the workloads to be altered ' either by specific workload, by user group workload~, or 1 acros-~ all workloads.
In addition, when certain changas to a system are made, I the workloads can be automatically redistributed in ! predetermined manners. Thi can be accomplished while still ¦ allowing an operator to fix certain branching probabilities.
1l 2. Modelin~ in~erface overview.
Figure 3ta) shows a preerred implementation 300 of a modeling interface in accordance with the present invention ~I which can provide the~ features described above. In the ',l preferred implementation, modeling interface 300 receive~ its I input about a computer system configuration from an .MDL file 305.
~ho .MDL file could be generated in many different ways.
One way i~ de~cribed in U.S. Patent No. 4,849,879 to Chinna~wamy et al., di~cu~ed in the Background of the Invention. Other technique for generating the configuration -I~NE~ HENDER50N i information are also po8Ribl~.
F.~R.~30W G~RRETT
~i DIIN~ER
~00 1 5TI~EET. N.
W~INOTON. OC 20005 i JIIJZo;l ~OO-~OOO I~
ll 2~ 3'~
Il 1 ¦¦ The output of modeling interface 300 is another .MDL
file 345. In the preferred implementation, .MDL files 305 and 345 have the same format but different data. .MDL files 305 and 345 preferably contain two types of data. One ~ype of data, device data, describes the devices in the computer system being analyzed as well as the interconnection of those devices. The other type of data, workload data, describes the workload~q on the system including information on workload distribution by use group and device. The specific format of the .MDL file, however, is not important to the present i invention.
In addition, initial values of per~ormance metrics can be supplied, but such value~ are not necessary to the present ! invention. If such inLtial valueY are supplied, they can be lS ¦I provided in the .MDL file or in qome other file.
Modeling interface 300 is a preferred implementation of the modeling system of the present invention. Modeling interface 300 includss parser 310, data storage 315, di~play/
'` keyboard 320, changar 330, QNM solver 335, and par~er 340.
~, Parser 310 is u~ed to translate ~he data from the format ¦~ stored in .MDL file 305 into an appropriate format for ,I storage into data storage 315. AR such, par~r 310 acts as a ~I type of compiler.
¦I Data storage 315 stores in a structure context portion 1~ 317 information on the configuration of the computer system ~ AwOrrc~ il being modeled and analyzed, as well aq information on I~;~E~A~ HE~;DER~O~
F.^RABOW. C~RRETT 11 ~ D~N~ER !; workloads, user group~, and MSCP relationship~. Data storage 1000 I gTRl:ET, N. W.
W~S~INGTON, 0C 20005 : .
1 202'400'-000 ,;
1, I I 2 0 ~L r~
1 11 315 ~tores that information in an easily modifiable form, preferably in a type of tree ~tructure, so that ch~nges to i the configura~ion can be easily effected. Data ~torage 315 i also contains performance metrics of interest in structure context portion 317.
; Data storage 315 also includes a display context portion 318 which contains information about the data being displayed. For example, display context portion 318 preferably includes information regarding screen position, , object being displayed, and performance metrics being ~ displayed.
" Di~play/keyboard 320 include~ a scxeen to di~play the configuration of the memory ~ystem, including information l~ about the system device~, the interconnection of thosa jl devices, and the worklo~d~. Display/keyboard 320 can also display information about u~ex groupc and performance metric~. All of the information di~played by display/
Il keyboard 320 i ba~ed on the information stored in the 1, structure con~ext portion 317 and display context portion 318 1l of da~a storage 315.
¦ Display/keyboard 320 includes di~play logic 322 which j~ acce3aes the information from display context portion 318 and structure context portion 317 to generate the di~play~.
l Ba~ically display/keyboard 320 acces es di~play context portion 318 to determine what information from ~ructure AwOrrccO l¦ context portion 317 to display and how to display that . INNIECAN. HENDER50~ ¦ !
FARAEOW. GARRETT , j I~DwNER !l 1300 ~ STR~E8 N. W.
W39~1NGlON OC 2000 ~202 408-4000 Il -17-I 2 13 ll ji j il, 1 ll information. The hardware and software to implement suchfunc~ion are known to persons skilled in this art.
Display/keyboard 320 also receives inputs from operators ~ requesting modeling interface 300 to modify the configuration or to perform other tasks. Those input~ can be received from keyboard commands or from devices, such as a mouse, which allow for screen selection. The inputs are buffered and I output by keyboard logic 323 to data storage 315, changer 330, and QNM solver 335.
`I Changer 330 receives the input from display/keyboard 320 and converts those requests into set~ of commands for other elements of modeling interfac0 300, such as data Il 3torage 315. At the appropriate time, changer 330 al80 ¦1 causes the necessary data from d~ta storage 315 to be I transmitted to QNM solver 335.
QNM solver 335 receives from data storage 315 modeling jil information describing the configuration of the computer I system being analyzed. That modeling information also jl includes workload parameter, uYer group information, MSCP
1I relation~hip~, and ~y~tem parameter3. From the modeling ¦1 information, Q~M solver 335 determines what certain performance metrics would be for a system operating according to the recaived modeling information. QNN solver 335 then ll store3 tho~e performance metric~ back into data storage 315.
'1I Parser 340 acts in a manner complementary to parser 310 ~worrlcc, by tran~forming the information from the format of data iECA`I. HE`iDER~O~ j 8D~;~ER ! storage 315 format back into the .MDT. format. In response to 1300 I STREET, N. W~ j i WA9NINOTON. DC 20009 I `Z02 .-09-. 000 1 i , I
~7~ ~
1 ¦ an operator request recei~ed from display/keyboard 320, data sTorage 315 transmits the configuration and metrics ~ information through parser 340 into .MDL file 345.
I Figure 3(b) shows an al~ernative implementation, modeling interface 350, in accordance with the present invention. Modeling interface 350 differs from modeling interface 300 in its use of parsers already employed for the .MDL files.
Il As in modeling interface 300, .MDL file 305 provides ~1 input and the .MDL file 345 recei~e~ the output from the modeling interface 350. Parser 360 i a parser u~ed in conventional systems for .MDL file Parser 360 translate~
~i the .MDL file 305 into an array. An interface 365 i8 added ¦ to parser 360 to provide final translation from the array ll into trees for data storage 315.
Another standard par~er 3gO i~ added to convert the , information from the tree format used by data storage 315 'I into array format3 for QNM ~olvex 335. Parser 390 also is Il u~ed to convert information from the array format which is an ¦¦ output QNM ~olver 335 back to the tree format used by data ~torage 315. Thi~ conversion also involves interface 365.
~¦ Finally, par~er 390 provide~ data conversion from the tree I¦ format for data ~torage 315 into a format for 3torage into !1 .MDL fila 345.
1; 3. Modelina intarface operation.
~WO~C~ Figure 4 is a flow diagram 400 generally howing the ~ D~;NNER ¦! 8tepQ performad during op~ration of th~ preerred 1300 1 5T~ ~, N. W. . i WA9~1NOl'ON. DC Z0009 I j ~ 20Z'~0~ 000 l j -19-1 ,l implemen~ation 300 of the present invention. At ¦ initialization of the operations represented by flow diagram , 400, the modeling interface receives from the computer system ! being modeled data describing t~e computer system~s configuration (step 405). As explained above, in the preferred implamentation, this informatLon is contained in the .MDL file 305.
In addition, if the option is chosen, the modeling , intexface in accordance with the present invention can il receive initial values for selected metrics for the computer system (step 410). The~e metrics would preferably be part of DL file 305, bu~ they could ~o provided in other way~, ~uch ~i as by operator input through a di~play/keyboart 320, or by ~ input from a differen~ file. The initial values of the l metrics received from the computer system will generally be values that were actually measurad during the operation of .l the computer ~ystem.
Il In a preferred impl~menta~ion, this receipt of 1 information i~ accompli~hed by choo ing a FILE option from a il modeling interface main menu 500, shown in Figure S(a), that ¦ appe~r~ on display/keyboard 320. Main menu 500 preferably allow~ ~eloction of one of ~everal options. In addition to j tho FILE option, there is al~o a S~T option, an ~DD option, a Il MOVE option, a REMOVE option, a DUPLICAT~ option, a VIEW
j option, and a SOLVE option. Thase options will be de~cribed ~worrlcc~ !l in greater detail below.
~IN1`:ECA~; HENDER50N 1 FARABOW G~RRETT
1300 ~ gTQIEl!:T. N. W. . ~
W~I~INOl'ON. 0C 2000~ 1, 1~202'~09 4000 ' ' 2 ~3 L~ 7 ~
1 I The FILE option is preferably selected by standard '¦ method~ of moving a cursor to a desired location on a menu displayed on display/keyboard 330 and then indicating a I selection. Once the FILE option is selected, a submenu S I appears that gives an operator a choice either to load a ;I model file (FILE LOAD), such as the .MDL file, into data storage 315, to write the model file to an .MDL file on a disk (FILE WRITE), to exit the modeling session and some the I changes in an .NDL file (FILE EXIT), or to exit the modeling .¦ session without saving the changes (FILE QUIT).
When the FILE LOAD option is chosen, ~he name of the i file mu~t also be provided. When the FILE WRITE option, FILE
!i EXIT option, or FILE QUIT option is choRen, no other Il information is needed. Choosing the FILE WRIT~ option does lS 'I not end the modeling session, but choosing ~he FILE EXIT and ! ¦ FILE QUIT options do.
Returning to Figure 4, after receipt of the configuration and initial parameter information, a model of I¦ the computer ~ystem configuration i8 created in modeling ¦1 int~rface 300 from the received information (step 415).
Preforably, either parser 310 in Fiqure 3(a), or the combination of parser 360 and interface 36S in Figure 3~b), build the model of the computor system configuration by placing the received configuration information into ~he ~; proper format for ~torage in data ~torage 315. The details L~W orrlC~ i I of the data format and preferred structure in data storage INNECAN. HENDER50~; ! I
F.~R.~80W. CARRETT ~
L~ DU~ER ! 315 are dlscussed below.
1300 ~ gTRCET. '1. W.
W~3111NOTON. DO 20003 1 1`202 40!~ -000 1 21-I
7 ~ 1 ?
, ext, a diagram of the configuration of the computer ! system, i~ di~played on display/keyboard 320 (~tep 420).
Ini~ial ~alues of certain selected metrics may also be displayed if such values were provided. Figures 2 and 5(b) show examples of such a display. Figure 5(b) is a diagram of a model display 505 showing workload information, workload parame~ers, devices, and performance metrics.
~odel di~play 505 preferably include~ a ~tatu~ lin~ 506, a list of workloads 507, and a di~play of the current model 508. One of the workloadq (Workload l), called a curren~
workl~ad, is highlighted. The information in ~tatus line 506 ` preferably includes the dioplay mode, the name of the model, i the name o~ the current workload, and ths name of a sourca I CPU. The display mode, a3 explained in greater detail below, I specifies which data is displayed in model display 505. The source CPU is the originator of the portion of the current workload.
Figure 5(c) show3 a m~s~age window 509 which is Il preferably overlaid on model di~play 505. Message window 509 jj includes message text, ~uch as messsge~ either from the modeling interface itself, broadcast messages, 6uch a~
¦ electronic mail, or operator mes~age~.
gure S(d) show~ a statu~ window 510 which can be !I di~played by making appropriate ~election~ on display/
1I keyboard 320. The statu~ window preferably provida~
.~vOrrlccg 11 information about the current CPU, the current workload, the Fl~ ;EGAI~; HE~DERSO~;
FARA~O~:C'. 5ARRET~ I
~ DU~ER j display mode, the balancing mode (explained below)~ the ~300 I ST~EEr, N. V.
~VASIllNOrON DC 20005 1 ~
202 ~0S " ' 22--!
., ~ ~3 '~
i 1 1l configuration being modeled, the status of the model, whether ¦ the mod~l has been solved, whether the model ha~ been " modified, and the name, if any, of the model library. The ,I model library is a library which overrid~s the default parameters of the devices modeled. Thi~ allows an operator to modify device parameters in the model.
After display of the system, the next step in flowchart 400 is the receipt of an input to modify the configuration of , the computer system (Step 425). The inputs can either ~ indicate a modification in the number and types of workload, the distribution of the workload, the number and type~ of ~I physical devices, or the connection of tho~e devices.
jl The preferred manner of making changes T~O the workload il involve~ use of the 5ET option from main menu 500 in Figure ¦ 5~a). The SET option allow~ an operator to set variou~
I parameters for the workload~ or variou~ attrlbutes for the ¦ modeling se~8ion.
I one of the SET options i~ the SET Di~play Mode option 1 which determines what information will be displayed for an ,1 identified ob~ect. In the preferred implementation, the SET
Display Mode option allows an operator to choose to display l branching probabilities, rate~ such as in TPS (tran~actions i per second) or IOs/second, percentage utilization, ~ervice I time (time to proce~ a reque~t) respon~e time (~ervice time ~1! plu~ queuing delay), yueue len~th, throughput (in IO t~ec)~
~wO~c~ and type3 of device3.
;EG~. HE~:DERSO
F.~R~90W. G~RRETT
8 DU~ER 1 1300 I STI~EI T, N. W. ' W~NOTON. DC 20005 ¦ ¦
t!Z02 ~0~ 4000 I j - 230 i l li '~ 2l3~7~j l 3 1 li In the preferred implemen~ation~ two of the display mode~, percentage utilization and queue length, will result in tha values flashing on the screen to indicate possible I problem condition~ The u~ilization value will flash if it exceeds a saturation point, which is set by default to 90~.
The queue length value will flash if 2 or greater.
In addition, when any changes are made to the model that might affect the performance metrics, such as the removal of ~ the device, the performance metrics that may be affected are ;' displayed in bold text to indica~e that they represent stale data.
Figure 5(e) i~ a diagram of a di~play 511 that would appear on display/keyboard 320 if the SET Display Mode option ~i were chosen. The different types of Display Modes are shown I in a window overlay, and the presentation of the ~probabilities~ entry in revar~e text indicates tha~ this is the Display ~ode being chosen.
Upon choosing the probabilities Di play Mode, a di~play l! 512 shown in Figure 5(f) would appear. Next to the ¦ representation of each device i9 in di~play 512 i~ a value in ¦¦ parentheses rapresenting the branching probability of that device for the current workload. In Figure 5(f), the current ¦ workload i~ workload-1.
llIf the SET Current Workload op~ion is chosen, a screen ji515, such as shown in Figure 5(g), i8 genera~ed showing the AW orr-cr~ Current Workload" option highlighted in rever~e text.
-INNECAN HENDERS;)N I;
FARABOW GARRETT j I
~i 3~'NNER
1300 1 5T~EEr. N. W. . j W~1~.070~. OC 2000 r202 ` ~03- 4 !
2 ~ ll 7 ~
1 1I The selection of ~he ~Curxent Workloadl~ option causes a I¦ diYplay 517, shown in Figure 5(h), to appear on display/
il keyboard 320. Display 517 allows an operator to choose to I display ei~her a designated workload or source CPU.
. If the Source CPU option is chosen, as indicated by the reverse text in display 517 of Figure 5(h), then a display 518 as shown in Figure 5(i) appears on display/~eyboard 320.
Display 518 shows the various CPUs in the computer system I being modeled.
I The operator would then choose one of the CPUs, such as .I CPU-5 in display 518 of Figure 5(i)l as shown in the reverse ',¦ text. This choice i~ then reflected on the sta~us line in display 519 of Figure 5(~).
I If a new workload or Source CPU i~ ~elected during the 1l SET Current Workload option, the information displayed in I paren~heses on the displayY will likely change if the Di~play ¦ Mode is "probabilitLes," or "TPS & IOs/sec." This is because ¦¦ the information di~played in the~a Display Modes represents a ,I percentage or actual I/O rate from the curren~ Source CPU and i workload. Changing the CPU or workload would likely force a changa in tho corre-~ponding information.
If the SET Balancin~ Node option is chosen, then a . di~play 520 as sho~n in Figure 5(k) apps~rs, which allows the ! Balancing Mode to be qet. The Balancing Node determine~ how ~5 . workloads should be redi~tributed among ~hs devices in a .,worrlc~ model when a change i~ made to the model that will affect FIN~EGA~; HE~:DERSO~
8 D~ER .I that workload. For exampl~, the removal of a disk causes the 1300 ~ STREET. 11. W.
W~9Y~I`IOTO~. DC 20005 j I 20Z''1O~ 000 --25 'r~ 7~
1 ,i I/O for each workload on that disk to be shifted to other l di~ks connected to the same CPU or HSC device. How the workloads are redistributed is determin~d by the Balancing ! ~ode.
` Workload distribution involves branching probabilities.
; As explained above, branching probability is a percentage of work supplied by a device for a given workload. Before solving a model, the branching probability for each workload must equal 100~. The probabilities can either be FIXED at a specific value or FLOATING. FLOATING probabilities can be adjusted to ensure that the sum of all related branching probabilities equals 100~. The balancing mode recalculations only affect the probabilities that are FhOATING.
'IIn the preferred implementation, a workload on a device lS such as a CPU or di~k can be apportioned among other devices jj in a set of device~ in two different ways. The relevant set jl of devices are those which can supply a greater or lessor i, amount of system re~ources to a particular workload. The set 1~ of devices would not include those with a FIXED probability.
I In uniform apportionment, the total amount of the ¦¦ ad~u~tment made for a dovice is divided equally among the !I device~ in the set. For example, if there were three CPU~, ¦11 and the branching probability for one CPU dropped by a II certain amount, the remaining two CPUs would have their ~I branching probabilitie increased by an amount equal to half ~AwOr~c~, ,! of the amount ~hat the first CPU's branching probability . INNE~AN HEN'DERSON ~ ¦
FAR.~aOW. G~RRETT l; d d ~ D~NNER I I roppe .
1300 I STRI:ET, N. W.
WAI~ OTO~. OC 20001 1 .
~`202 40~ 4000 , --26--!
7 .j ~ ~
1 I In relative apportionmen~, the total amount of the ad~u~tment i8 made proportionate ~o the ratios of branching probabilities the de~ices in ~he set. This insures that the ratios of branching probability for the devices in ~he 5et remain the same. In other words, if one of the two CPUs in the prior example has a branching probability for a workload which is twice as large a~ that of the other CPU, then two-thirds o f the workload needing to be allocated would go to the CPU with the larger branching probability.
Related to the SET Balancing Mode option i9 the SET
Probability Distribution option. If thi~ option is chosen, a display 522 a~ shown in Figure 5(1) appear~ on display/
keyboard 320. Di3play 522 pre~ents the operator with a choics of devices for which to ~et the probability. By the reverse text, display 522 shows that the operator has chosen to set the branching probability for a CPU. The next display to occur, which i5 not ~hown, contain~ a list of all the CPUs whose branching probability can be changed. When an appropriate CPU iY chosen, then the operator is prompted to i enter the branching probability for that CPU (or other device ! I cho en). In addition, in the preferred implementation, the opera~or i3 prompted to set the probability to FIXED or FLOATING.
Branchin~ probabilitie~ may al~o be modified indirectly l by deleting hardware and moving workload~ between device~.
~O~r~CC~ ¦ When the modeling interface i~ fir3t invoked, all branching INNE~ AN HENDER50N I
~ D~NNER I probabilitie8 ar~ ~et to FLOATING and ad~usted 30 that the 1300 I STflEET, N. ~V, I
~ASHIIJOTON. OC 2000 ,.20z40e~ooo -27-,1 2 ~
1 I branching probabilities for each workload add to 1Ø The ¦ FIXED probability attribute is used to indicate that a workload distribution should remained fixed for a given CPU, disk, or user group despite other changes that may af f ect certain workloads. Preferably, the branching probability is only fixed for the duration of a particular modeling session, and is not transferred into the .MDL file.
Workload parameters can al~o be set ~y using the S~T
Workload Parameters option for the display mode. If the SET
Workload Parame~ers option is chosen, a workload display 525, shown in Fi~ure 5(m), appears. Workload display 525 includes a list of workloads that have parameters which can ba modified. Once a workload is ~elected, ~uch as the Z-i FREQUENCY" workload shown in reverse text in di~play 525, the I workload parameters which can ba modified are displayed. A
i display 528 of tho~e workload parameters for workload Z-frequency is shown in Figure 5~n)~
AR iR apparent from di play 528, the workload parameters that can be changed in the preferred implementation include the transac~ion per ~econd (TPS) required by the associated ¦ workload, the numbers of instruction per ~econd (in j thou~and~) required by the workload, the number of I/Os per j tran~action ~or that workload, the ~ize of the I/O per I transaction, ~hown a~ di~k transfer sizs, for that workload, 1 and the number of locks per tran action. Locks are a .AwOrrcc~ ' cluster-wide synchronization mechanism to control acces~ to . INNEC~N, HENDERSOI`; I
FARABOW. GARRETT
~ DUNNER I common resourc~s.
1300 1 9TR~El', ~1. W.
WA5~ 5TOr~. OC Z000 1 20Z-.10~ 000 2 ~ 1l 7 C~
1 ¦ In addition, one can choose whether to indicate disk branching by SOURCE CPU. If the workload ha~ disk branching by SOURCE CPU, each CPU's I/O distribution depends on the CPU
running the workload. If not, there is common disk branching, and the I/O distribution across disks is the same regardless of which CPU is supporting the workload.
Th~ SET System Load option behaves in a similar manner.
If this option is chosen, a di~play 530 shown in Figure 5(o) ~ appears to allow an operator to change the load of the computer system either by workload, user group, or overall throughout the system. For example, one could double a particular workload, double the workload provided by a particular user group, or double the workload throughout the ! System.
` Once the SET System Load option and the manner of workload modification i~ cho~en, the operator i~ prompted to enter the parcentage load change and indicate whether the load is to be increased or decreased. After changing the ~ load, the SOhVE op~ion for the model mu~t be cho~en to 3ee I the effocts of the new load.
The SET Ob~ect Nc~me option can be used to change the name of an ob~ect. Ob~ects include model~, bu~ses (~uch as CI or NI), bus adapterc, CPU~, HSC~, channels, di~k~, ! workloads and user groups ~fter the SET Ob~ect Name op~ion " is selected, and ~he ob~ect i identified, the operator is ~wo~rlc~9 i prompted to supply the new ob~ect nc~me.
ECA~ HE~;DERSO~
hR.~3QW GARRETT
~D~ER
1~00 r 3Ta~r l, N. W.
lNOTON 3C 2000 I--Z02 40~ 000 ~ ' .
2~/~7 ï 3l :~
1, 1 ~ In a ~imilar manner, the SET Object Type option can be I used to change the type of bus adapter, CPU, H5C, or disk.
I If thi~ option is chosen, a display 533 shown in Figure 5(p) ! appears on keyboard/display 320 ~o indicate the device choices. Once a devlce is chosen, such as a disk in display 533 of Figure 5(p), a new submenu is overlaid indicating the different devices of the t~pe chosen. That submenu, shown as display 534 in Figure 5(q), show~ all the different disks in , the computer system.
When one or more of tha devices are chosen, then display 535 in Figure 5(r) is selected to indicate the pos~ible types of the ~elected device~. For example, in display 535 of Figure 5(r), the RA60 type of disk ha~ been selected.
In addition to s~tting workload distribution3 and system i parametexs, physical device3 can be added, deleted, or moved.
When the ADD option on the main menu 500 of Figure 5(a) is selected, then a display 540 shown in Figure 5(s) appears.
~he ADD option allows one to add a model, a bus (CI or NI), i an adapter, a CPU, an ~SC, a channel, a di3k, a workload, a user group, or MSCP ~erver information.
In display 540, the reverYe text indicates that a CPU
has been cho3en to be sdded. This caus~ the display 542 3hown in Figure 5(t) to appear on diYplay/keyboard 320.
Display 542 indicateR the different type3 of the CPUs which I can be added. In adding a CPU, an operator would al~o be .AWOr~cc, j a~ked to ~elec~ an adaptor by making a 3election from a INNEGAN, HENDER50N .
~ DUNNER I screen li8ti~g po88ible adapt~r~.
1300 ~ 9TR~T, N. W.
~'IAS~INOTON. I~C ZOOO~ j ,202~09-~000 _30_ ~ i ~v O .il ~
1 1 The manner in which the modeling interface determines i where to add the devic depends upon the type of device. For disk~, the operator is asked for the CPU or HSC channel to j receiving the di~k. CPUs, on ~he other hand, are added to the most recently identified bus and must be moved if necessary. This mechanism, however, is just the preferred implementation and is not required to practice this invention.
, If the DUPLICATE option is chosen from main menu 500 in Figure 5(a), a display 545 shown in Figure 5(u) appears. In the preferred implementation, the elements which can be duplicated include a model, a buq, an adapter, a CPU, an HSC, I a channel, a disk, a workload, a user group, or MSCP server ;i information. If ~he CPU option is chosen, as indicated by the reverse text in display 545, a display 547 as ~hown in Figure 5(v) appears on display/keyboard 320. Display 547 l indicate~ the possible CPUs which can be duplicated. The i device chosen is then duplicated. Both the chosen device and the duplicate device have the sams physical connections to `; the other device~.
To change a connection, the MOVE option in main menu 500 of Figure 5(a) i~ cho~en. If this option is chosen, display 550 ~hown in Figure 5(w) appears. The move option allow~ an , opera~or to move an adapter, a CPU, an HSC, a channel, a ,I disk, or a workload. If a disk is chosen ~o be moved, as ~AwOrrl~c~ !¦ shown by the reverse text in display 550, then a display 552, -INNEGAN. HENDERSON 1 8 D~NER I ¦ shown in Figure 5(x), appears.
1300 I STREET, N. W.
WA5111NOTON. OC 2000!1 1 202 -09 -000 ' .
~ f~ ~L r~ ~3 -/ J
1 1 Display 552 lists all the possible disks that can be I moved in the computer system. Using display 552, the operator chooses the disk, called the source disk, to be moved.
When moving a source disk, the CPU or the channel to which the source disk is to be moved mu~t be chosen. In the preferred implementation, this selection is accomplished using a display 553 shown in Figure 5(y), which appears on display/keyboard 320 after a disk is selected.
Display 553 indicate~ whether the disk is to be moved to a channel or to a CPU. In di~play 553, a CPU ha~ been chosen, as indicated by the reverse text. The selection o~ a CPU cau~es di~play 554, ~hown in Figure 5(z), to appear.
Display 554 list~ the po3sible CPU~ to which a di~k can be moved. A~ shown in display 5S4, ~he source disk is to be moved to a target CPU identified as CPU-7.
A physical device or workload can also be d~leted from the computer ~ystem configuration using the R~NOVE option in ' main menu 500 ~hown in Figure 5(a). Selection of this option cau~e~ the appearance of a di~play 555, ~hown in Figure 5~aa). Di~play 555 indicates the types of devices which can be r~movcd. Di~play 555 show~ that a CPU ha been chosen, which cause~ a display 557, shown in Figure 5(bb), to appear.
1 When a dsvice i~ to be removed, the opera~or i~ asked for a confirmation because removal of a device ha~ far-reaching ~worrlcc~ effect~ that are difficult to undo in the preferred INNECAN HEND~RSON, FARA~~ C~ERRR~T~ ' implementation. Al~o in the preferred implementation, 1300 I 9TFIEET, !1. W.
~VA9111~ T0~. OC Z0009 1 20Z ~0~'~000 1l --32--~ 7 ii `
1 removal of a device removes all devices connected to that device.
Returning to Figure 4 and flow chart 400, the next step I after receiving an input is the modifica~ion of the model of the compu~er system in accordance with received input to reflect the modified configuration of the computer system (step 430). Modification using the SET option uses the keyboard logic 323 and data storage 315. Modification using the ADD, DUPLICATE, MOVE, and RENOVE options uses changer 1 330. The details of how such modification occur~ in data storage 315 will be described in greater detail below.
If a change has been made which affect th~ distribution I of the workloads, the new workload distribu~ions must be I determined (step 440). The steps for redistributing are I shown in greater detail to the side of flow chart 400.
Redis~ributing involve~ identifying a set of physical ¦ device~ in the computer system to which the load will be redistributed. The device3 in the set are those which also support th~ workloadA as the identified physical device (i.e., I the one added or removed, or the one which had its workload altered) (step 443). For example, if a CPU had four disks and ona wa~ r~moved, the remaining three would constitute the set of physical devices involved in redistribution.
i The workload3 are then redistributed among the member~
of the set according to ~he ~alancing ~ode (step 447). ~his LAwO~rcc, redistribution requixe~ first determining which members of INNEGAI`;. HENDERSO~:
FARAsowGARRETT the set have FLOATING probabilities, and then distributing ~ DUNN~ER
1300 I STI:IEET, rl. W.
W~5il1NOTON. OC 2000~ ¦
~ 202-40~1 4000 1 _33_ ,1 'I
2 ~ 1 r~
1 I the probabilities among those members in accordance in the Balancing Mode Next, new values of the selected metrics for the I modified model of the computer system are determined (step ' 450). Preferably, this is accomplished by selecting the SOLVE option from main menu 500 shown in Figure 5(a).
After the new valu~ for the metrics are determined, the diagram of the modified configuration of the computer system, I with new values for the metrics, are displayed on display/
I keyboard 320 (step 460). The resulting displays have current information.
As example~, display 560 in Figure 5(cc) result from the addition of a CPU. Display 565 in Figure 5(dd) results from the movement of a disk. Display 570 in Figure 5(ee) results from the removal of a CPU. Display 575 in Figure 5(ff) results from the duplication of a CPU.
¦ Another feature provLded by the pre~erred implementation is the VIEW option which allow~ an operator to examine specific portions of a model. The view option permits a one ' level ZOON capability to ~how more detail. For sxample, if the VIEW option i~ chosen from main menu 500 in Figure 5(a), then ~ display 5R0 (Figure 5(gg)) appQars on display/keyboard 320 prompting the operator to indlcate which elements are , desired to be viewed.
If as indicated in display 580, a CPU is to be viewed, LAwO~rc~, then tha focu~ of the model i8 on the new CPU rather than on F I~NEG~; HEI~;DERSO~; .
FARI~SOW G~RRETT
~!1 Di,'~:~ER
laOO 1 5T~ T, N. \N.
OT~N, OC ZOOO~
,z0240g-4000 -34-I
~ O '1 7 ~
1 ¦ the entire model or some other de~ice. The display 582 in Figure 5(hh) then appaars.
Display 582 allows an operator to selec~ the CPUs in the I system to be viewed. If, as indicated in display 582 in ~ Figure S(hh), CPU-7 i5 chosen, then display 584 aq shown in Figure 5(ii) appears showing the CPU-7, it~ adapters, and the busseq to which it i~ connected in greater detail.
B. Data Structureq 1 Figure 6 is a block diagram of a model 600 showing the `¦ relationship between individual data s~ructure6 ~tored wi~hin ¦ da~a storage 315. The root of model 600 i9 the model roo~
610 which identifies a model for a computer sy~em created from the .MDL file and which is repre ented in a node deqcribed below. Model root 610 has five children, all of which interrelated, as described in detail below.
; Two of the children, the CI tree 620 and NI tres 630, ~ogether con~titute a device data ~tructure. Workload tree 640 is a data structure ~howing the relationships of the ,I different workloads to different devices. U~er group tree 1 650 i~ a data structure showing the differen~ user group~ and their relation~hip to different workloads. MSC~ tree 660 is a data structure ~howing the rela~ion~hips of device~
provlding ~SCP service~
, Although in the preferred embodiment, ~rees 620 660 have a modified treo da~a ~tructure, such a structure 1~ not ~wOrc~ ! strictly required to prac~ice the presant invention. As will -INNE(;AN HENDER50N ¦
F~R~BOW, G~RRErr 8 DUNNER I be apparent from the ds cription of the invention which 1300 1 9TREET, N. W.
W~9111N~3TON. OC ZOOO!S .
I Z02 .109-~000 .j Z ~ ll 7 ~ ~ ~
1 1 follow~, one advantage of a tree structure is the ease by which modification~ may be made to computer system configurations. Persons of ordinary skill in the art will recognize ~hat other data struc~ures which permit easy modification may also be used.
1. Device Data Structure.
An example of a CI tree 620 and an NI tree 630 are shown , in greater detail in Figure 7. In Figure 7, a device data i structure 100 is represented a~ including both a CI tree and 1 an NI tree. The particular configuration represented by j device data struc~ure 700 i~ that of computer system 100 I shown in figure 1.
¦ The CI tree 701 includes a CI root node 710 which has, ! as children, nodes for ~SC 140, represented by HSC node 720, l and adapters 112, and 123 for the CPUs coupled to CI bus 106 ¦ in Figure 1. Node 705 correspond~ to adapter 113, and node 706 corresponds to adapter 123. The child of adapter node , 705 i8 CPU1 node 730 corresponding ~o CPUl 110, and the child ¦ of adapter node 706 iR CPU2 node 740 corre~ponding to CPU2 1 120. The children of the HSC node 720 are channell 150, ! represented by channell node 721, and channel2 155, repres~nted by channel2 node 725.
Th~ children of channell node 721 are nodes representing I diskl 160 and disk2 162 (Figure 1). These node~ are diskl 1 node 722 and disk2 node 723, re~pec~ively. Similarly, the ~worrlcc~ ' child of channel2 node 725 is disk3 node 728, which 1!~;8;ECAN, HENDERSON ¦
FARA80W. CARRET~ , ~ D~N~R ' correspond~ to disk3 164 (Figure 1).
1300 1 9TRl!:Cr, N. W.
WAS~ OrO~`I. O C 20005 I 202 .0~1-4000 ;l -36 , .
I 2 0 ~ 7 ~ ~ ~
1 ` CPUl node 730 has a single child, disk4 node 735. Disk4 I node 735 corresponds to disk4 166 (Figure 1).
The NI tree 702 includes an NI root node 760 which has as children adapter nodes 707, 708, and 709, corresponding respectively to adapters 112, 122, and 132. The children of adapter nodes 707, 708, and 709 are respectively CPUl node 730, CPU2 node 740, and CPU3 node 750, corresponding respectively to CPU1 110, CPU2 120, and CPU3 130 (Figure 1).
I CPUl node 730 and CPU2 node 740 have already been described above in the discussion of CI tree 701. CPU3 nod~ 750 has ¦ two children, disk5 node 752 and disk6 node 753. Disk5 node 1 752 corresponds to disk5 168, and disk6 node 753 disk6 node ¦ 170, both in computer system 100 ~Figure 1).
¦ Device data ~tructure 700 include~ node~ each of which I correspond to a different physical device of the computer ¦ system represented. Fi~ure 8 shows a diagram of a preferred implementation of a generic node 800. The node is called generic because it can be used, with slight modification, as I a node for model root 610 or any of the trees 620-660 shown in Figure 6. Node 800 has ~everal fields 810-860.
Name field 810 contain3 tho name of the element represented by the node. The contents of name fiald i~
preferably a string.
Statistics record list head 820 for a device.identifies i the location of a linked list of stati tics element~ 821 each ~worrlcc~ ¦ of which contain3 certain stati~tic~ for a workload ~upported INNEC~N HE~;DERSO1~; ~
~D~ R l by the devic~. For a d~vice, stati3tic3 record 821 includes 1300 I STi~CET, N. W.
W~3~1NOTON. OC 2000~5 1'202'40el 4000 1 37 . ' 1 1~ a rate ~ubfield 822 indicating the number of processing tran~actions (TPS) or I/O tran~actions (I/Os) from the device for the corresponding worXload. Queue length subfield 823 indicates the length of the queue that is waiting to use the device for the corresponding workload. Service time subfield 824 indicates the amount of time that takes the device to process a request for the corresponding workload. Response time ~ubfield 825 equal~ the service time plus any queuing I delays. Utilization subfield 82b indicate~ the percentage of I the devices capabilities currently being utilized for the corresponding wor~load. Workload pointer 827 indicates the node for the corre~ponding workload.
I In addition, there is an additional statistics element ¦ in the linked list. Thi~ element has the compo~ite l ~tati~tics for all o the workloads of the device.
The stati~tic~ t head for workload nodes has entries for rate field 822 indicating the throughput for the entire workload, and for re~pon3e time ~ubfield 825, which I represents the time to complete an entirs transaction for I that workload. The workload pointer subfield 827 indicate~
the model node.
, All of ~he ~ubfieldR in ~tatistics record 821 are repre~ented as real number~, except for the workload pointer, and ~he values in all of the field3 except the rate field are I de~ermined a~ a rasult of performing ths SOLVE option. ~he .AwO~r~ccg jl value in the rate field i5 either input by a usar, or i~
I:~NECAN. HENDERSON ~ I
FARA80W~ GARRETT
~D~ ER ! received from tha .NDL fLle.
1300 1 9TPEET. N. V,l. I
5r~1~0TON. 0C 2000 I ZOZ 40~ 4000 1 1 The library pointer suhfield 830 of generic node 800 , references a library record specific to a device type. The library record describes parameters associa~ed with that I device type. For example, the library for a certain type of disk would contain its seek time, latency, transfer rate, etc.
Link array field 840 identifiei headers for various linked li~ts which relate to the element corresponding to I node 800. One set of headers i5 shown in detail in Figure 9 ~ as link header list 900. Link header list 900 include~ a workload linked list header 910, a paren~ linked list header j 920, a child linked list header 930, and an MSCP linked list i header 940.
l Workload linked li~it header 940 i~ a header for a linked ~ list of workloads which the corresponding device support4.
Parent linked list header 920 i~ the header for a linked list of nodes which are parents to the corresponding element node.
In a ~imilar manner, child linked list header 930 is the header for a linked lis~ of the children of the corre~pondlng ~0 element. MSCP linked list header 940 i~ the he~der for a linked li3t of MSCP tress involving the device corresponding to the node. In the preferred emhodiment, tha link header I list, and mors cpecifically the linked list~i, are specific to the different types of nodes.
Figure 10 shows an example of a linked li~t 1000 which .AwOrr,c., I can be u~ied as any of the linked list3 de~cribed above. In INNECAN. HENDER50N ~
FAR.~90W. GARRETT Figure 10, the linked li8t 1000 includ~s a list head typa ~ :~00 ! 3TR~rT, N. W. l WASl-llNaTON. OC 20003;
1 202' 4013-~000 . - 39-2, ~
1 1 1005 and link elements. List head type 1005 in turn includes a forward link 1030, a backwards link 1060, and a count 1080.
Forward link 1030 indicates the location of the first element ' in linked list 1000, backward link 1060 indicates the location of the last element in linked list 1000, and count 1080 indicates the number of elements in linked list 1000.
Linked list 1000 i~ called a doubly-linked list because it is linked in the forward direction ~hrough the forward I links 1013 and 1023~ and in the backwards direction through , backward links 1025 and 1015. Note that the la~t link element, element 1020, ha~ a forward link 10~3 to a nil i record 1095, and the first link element 1010 has a backward j link 1015 to a nil element 1090.
I Linked list element 1010 ha~ pointer 1018 which 1 identifies a corresponding node, and linked li~t element 1020 has a pointer 1028 to a corresponding node 1029.
Returning to generic node 800 in Figure 8, subfield 850 indicates the type of nod~. The different node type5 include , model type~, device types, worXload typas, branching types, ¦ u~er group types, and MSCP typa~.
! Associated with many of the type.~ of nodes is a variant record 860 which contain~ information unique to different ¦ node types. One example of a variant record i~ variant ¦ record 1100 shown in Figure ll(a) for a model node. It i includes as cubfield~ a device li~ pointer 1110, a selection ~wor~l~c~ j device pointer 1112, a configuration field 1114 defining the !NNECAN. HeNDER50N: ¦
FARABOW. G~RRET~
~) 3UI`;NER .
1~00 I gTRl!:~T, N Vl.
W~INOTON. OC ZOOO~
~Z02 0~1 AOOO
, 40-:, ~ ~ ~ 7 ! r 1 1 particular ~onfigu~ation type of the model, a modified flag 1116, and a solved flag 1118.
Figure ll(b) shows a model node 1130 including the ¦ variable record portion. The name field 1132 contains the name of the correspondin~ model. The statistic~ list head field 1134 and the library pointer field 1136 are empty.
The link array 1140 only has entries for the child linked list with header 1142. In the preferred embodiment ~I for model node 610, the linked list for header 1142 would j identify a list with nodes for the CI node 710 and the NI
node 760.
Élement type field 1145 identifies node 1130 as a model.
~ Select device pointer 1150 point~ to a list of items ! identifyin~ either a current model 1152, a current device, ¦ such as the entry for the current CI bus 1154, or a current ¦ workload ~not shown)~ The row and column entries identify j the location of ~he corresponding model, de~ice, or workload ¦ on the screen of display/kayboard 320.
¦ Device list pointer 1160 identifies list header for each of the compone~t~ of the corresponding model. Model list head 1162 i~ for a ~ingla element iden~ifying the model node.
CI li~t head 116~ i~ for a list 1170 of CI linked list ele~ent 1172 and 1174. Li~ts would al o exi~t for CPUs, l HSC~, di~k3, etc. Li~t 1170 indicates that the model , corresponding to node 1130 includes two CI busse~.
~worrlccg Configuration field 1180 iden~ifie~ the configuration of lI`i'NECAN, HE:`iDER50N . ¦ .
8 ~NNER i the corresponding model. A model can hav~ 3e~ral different 1300 ~ STFIE:~, N. w.
W~91~1N'3TON. OC 2000~, 202 40a-4000 41--!l I
~ .3 1 ~ configurations. Model 600, for example, is a mixed cluster configuration, another example of which is shown in Figure 12(a). Figure 12(b) shows a standalone configuration.
i Figure 12(c) shows a CI cluster, and Figure 12(d) shows an NI
cluster.
Modified flag 1190 indicates whether the model has been modified. Solved flag 1195 indicates whether the model has been solved (i.e., whether the SOLVE option has been invoked) after all the changes have been made. Modified flag 1190 and solved flag 1195 are Boolean values and together indicate whether any data is stale and should be displayed in bold text.
Figure 13 shows another example o a variant record, variant record 1300 for a device. Record 1300 includes an i MSCP pointer 1310 which identifie~ a corre~ponding MSCP tree if the device is a CPU or a disk.
I 2. Workload Data Structure.
¦ Also in accordance with the present invention, a I workload data structure includes a plurality of second data 1 entries each corre~ponding to a differ2nt one of the , workloads which the computer sy~tem support~. In the preferrod embodiment, the workload data structure i~ al~o a tree.
Figure 14 includes a workload tree 1400 for workload 1, and shows its relationship to a portion of a device tree .A_Orrc~ I 1401. That relationship i by way of branching IECA~;. HE~DER30t; . ¦
8 D~ER ! probabilities.
130Q I sn~ccr, N. W.
W~5~11NOTON. DC Z0005 ~ Z02 ' ~0 1 ' 4000 --42--I
2 n ~
1 1 The portion of the device data tree 1401 shown in Figure 14 includes CPU nodes 1455, 1460, and 1465 for CPU1, CPU2, and CPU3, respectively. CPUl node 1455 has as children three l disk nodes, diskl node 1475, disk2 node 1480 and disk3 node ' 1485.
Workload tree 1400 includes a workload root node 1405, I which has as children workload-l node 1410, workload2 node ¦ 1412, and workload3 node 1414. Workloadl node 1~10 has a~
j children a CPU branching probability node 1420 for CPUl, a ¦ CPU branching probability node 1422 for CPU2, and a CPU
I branching probability node 1424 for CPU3- This ~truc~ure ¦ mirrors the structure for device tree 1401.
CPU branching probability node 1420 has three nodes a~
children: diskl branching probability node 1481, disk2 branching probability node 1482, and disk3 branching probability node 1483, which correspond to di k node~ 1475, ¦ 1480, and 1485, re~pectively. This ~tructure al~o mirror~
the structure for device tree 1401.
CPUl noda 1455 is related to workloadl by branching 1 probability noda 1420. CPU2 node 1460 is related to I workloadl by branching probability node 1422, CPU3 node 1465 i8 related to workloadl by branching probability node 1424.
AB explained above, the branching probability for a corre~ponding device and workload is an indication of what percentage of th~ corresponding workload has services .AwOrrlc~, ~ provided by tha corresponding device. Thu~, aR represented INNEG,~N HENDER50N .
~ D~;NNER ; by branching probability nod~s 1420, 1422 and 1424, workloadl 1300 ~ 9TREET, N W.
W~9~11NGTON. DC 2000~
1'202 .~0~'~000 -43-2 0 '~
1 ! ha~ 80~ of its cpu 3ervices provided by CPUl, 5~ of its CPU
service3 provided by CPU2, and 15% of its CPU services provided by CPU3. The percentages in the branching I probabilitie~O must add to 100~.
The branching probabilities for the disks also add to 1 100%, although it should be understood that the percentages ¦ represented by the branching probabilities of nodes 1481, 1482 and 1483 represent only the percentage of the disk ' services which are provided for the portion of workloadl supported by CPUl. For example, the branchLng probability ¦ for workloadl provided by diskl is 30%, the branching I probability for workloadl provided by di~k2 iY 40%, and the .I branching probability for workload3 provided disk3 i~ 30~, ¦ but these are percentages of the workloadl ~ervice~ provided by CPUl. To determine the total amount of system resources : which diskl provides for workloadl, the branching probability ; for di~kl, 30~, ha~ to be multiplied by the branching . probability for CPUl, 80%. In this case, the re~ult of such ~I multiplication would yield 24%, indicating that di~kl provides 24% of the disk re ource~ required by workloadl.
! The workload data node ha~ the basic ~truc~ure of the generic node 800, except the library point~r 830 i~ not u~ed, and the linked list field does not include an MSCP linked . li~t 940. The variant reco~d portion for a workload node is ¦ shown in Figuro 15 as record 1500. The information provided ~worrlcc~ ¦ in the workload variant r~cord 1500 include~ the re~uired 8 D~;NNER txan~action~ per second provided in Hubfi~ld 1510, the 1300 1 9T~ El'. N. W.
W~ 3TON. ~C 2000 ~ C02 0- 0~0 _44_ 2 0 '~ 7 '~ J ~
1 1 required instructions per second provided in subfield 1520, the required disk I~Os provided in subfield 1530, and the required I/O size, provided in subfield 1540. In addition, ¦ workload variant record 1500 includes a lock subfield 1550 ~ which is the lock explained above, and a BY SOURCE field 1560 which was also explained above. All of the fields in variant record 1500 are real, except for BY SOURCE field 1560 which i~ Boolean.
I The branching probability node~ are al~o similar to the ~i, generic node 800, except they do not include a name field, a statistics list head 820, a library pointer 830, and element type field 850 and there is no workload linked li~t 910 or i MSCP linked li~t 940. ~he variant record for a branching I probability node i8 ~hown in Figure 16 aS~ record 1600.
, Record 1600 includes four ~ubfields. Float Stubfield 1610 contains a Boolean value indicating whether the branching I probability i~ FLOATING or FIXED, as explained above.
¦ Probability ~ub~ield lS20 contains ~ha corresponding Il branching probability. Norkload point~r stubield 1630 1l identifie4 the node for workload corresponding to this branching probability, and device pointer subfield 1640 identi~iQs tha nod3 for the corre~ponding device.
Fi~Are 17 i~ a diagram 1700 ~howing the l interrelationship betw~an various nodes for device and i workload treas. Diagram 1700 al~o indicates the field~ of .AwOrrc~, ~ each node which are actlve for the corre~ponding node.
-INNE~;~N. HE!`:DRSO~`;, hRA30~. CARRETT
9 D~NER
1~00 t ST~lU:r, N. W.
~IIN0TON~ 0C 20005;
1`202 40:~ -000 , -45-2 ~ ll 7 ~ I ~
.1 1 ¦ CPU device node 1710 includes a name field 1711, a library pointer 1712, a statistics list head 1713, and an elemen~ type field 1717. Pointers 1714-1716 are part of a link array. Workload pointer 1714 identifies a workload linked li~t of branching probability node~; parent pointer 1715 iden~ifies a linked list of nodes for the parents of CPU
device node 1710; and child pointer 1716 identifies a linked li t of nodes for the children of CPU device node 1710.
As Figura 17 shows, one of the children in the linked list which pointer 1716 identifie~ is a disk device node 1720. Disk device node 1720 represents a disk connected to the CPU represented by CPU node 1710.
Disk device node 1720 include~ a name field 1721, a library pointer 1722, a sta~i~tic~ t head 1723, and an element type field 1726. As part of its link arxay subfields, disk device node 1720 include~ a worklo~d pointer-to a linked list of branch probability nodas, and a parent pointer identifying a linked li3t of nodeR for parents of disk device node 1720. The parent linked list includes CPU
device node 1710. Disk node 1720 has no children ob~ects and i therefore ha~ an empty children linked list o~ child node-~.
¦ The branch pointer 1714 of CPU device node 1710 .¦ identifies a CPU branch probability node 1730 for the I worklo~d repre~en~ed by workload node 1750. CPU branch I probability node 1730 include a parent poin~er 1732, which ~wo,rlcc, I identifie~ workload noda 1750, and a child pointer 1733, EG~N. HE~DER501~; 1 FARA30W C~RRETT
~ DUN~ER ::
1300 ~ STQEET, N. V~.
W~N3TON. I:)C ZOOOS
I~Z02 40~-~000 2 ~ 4 7 ~ ~ ~
1 ~ which identifies a linked li3t containing the disk branch probability node 1740.
The CPU branch probability node 1730 also includes a ' float field 1734, a probability field 1735 containing the branch probability valuel and a type field 1738. ~orkload pointer field 1736 identifies workload node 1750, and device pointer field 1737 identifies CPU device node 1710.
The disk branch probability node 1740 is similar in content to the CPU branch probability node 1730, excep~ that disk branch probability node 1740 does not contain a linked : list for the children nodes. Parent pointer 1742 identifies CPU branch probability node 1730.
Workload pointer 1746 identifie~ the workload node 1750 ~ for the correspondin~ workload, and the device pointer 1747 lS l identifies the di~k devico node 1720 for the corre3ponding disk. DiRk probability node 1740 al o contains a float field 1744, a probability field 1745, and an element type field 1748.
.' The worklo`ad node 1750 contains an entry in the name , field 1752, as wall a~ entries for statistics list head 1753, parent pointer 17S5, and child pointer 1756. Parent pointer 17S5 identifies the model node, and child pointer 1756 , identifi~s a linked li~t with CPU branch probability node 1730 and a u~er group branch probability node 178p.
~¦ Workload node 1750 also contains entries for the L~wOr~lc~ ~! transactions per ~econd field 1757, tha instruction per INNE(;AN. HENDER501`; . ¦
~DuNNER , ~econd fi~ld 1758, th~ di~k I/Os fi~ld 1759, the I/O size 1300 1 9TR~ET. N. V~.
~V~3~11NOTON. DC 20003 I 202 ~oel-~000 ~ -~7-I1 2~ll7~
1 field 1760, the lock field 1761, the BY SOURCE field 1762, and the element type field 1763.
3. User Group Data S~ructure.
I As explained above, user groups are mechanisms which can be used to organize the sources of the workloads. Figure 18 shows an example of a user group data structure 1800 organized in a tree s~ruc~ure. The user group data structure 1800 includes a user group root node 1810, as well as nodes 1820-1840 corresponding to different user groups. In the ~ example shown in Figure 18, node 1820 corre~ponds to an engineering user group, node 1830 corresponds to a marking user group, and node 1840 correspond3 to administration uf2er ' group.
i The user group data structura includes a plurality of i third data entrie~ each correspondinq to a u~er group. The ~ user group data entries, or nodes, are similar to ~he generic 'I node 800, except that the user group nodes do not have a library pointer 830, a child list head 930, or a NSCP list I head 980. User group nodes also do not have a variant record in the preferred embodiment.
In Figure 17, user group node 1770 has a name field 1772, indicating the name of the corresponding user group, and an element type field 1777. User group node 1770 al80 ¦ include~ a parent poin~er 1775 to the model nods ~nd a , workload pointer 1774 to a linXed list for user group branch ~.~worrlcc~ 1, probabilities.
INNECA~. HE~DERSON
FAR.~BO~. GARRETT
~ DUNNER
1300 1 9TREET, N. W.
INOTON. 0C 2000~
~ ~ Ll 7 S, ;~
1 ¦ One of the entries in the linked li~t i~ user group branch probability node 1780. Branch probability node 1780 has a parent pointer 1782 identifying a linked list which , include~ workload node 1750. Branch probability node 1780 also includes a workload pointer 1786 identifying a linked list with workload node 1750. Workload node 1750 is in the ¦ workload linksd list for node 1780 because the user group ¦ corretponding to node 1780 contributes to the workload I corresponding to node 1750. Additionally, user group branch I probability node 1780 include~ a device pointer 1787 which ~i identifies the corresponding user group node 1770. This I pointer allow~ traver3al of the data ~tructure to find the I user group from the workload using ~he user group branching il probability nodes.
l User group branch probabLlity node 1780 also includes a ¦ float field 1784, a probability field 1~85, and a node type ¦ field 1788. Probability field 1785 indicates what percentage of the corre3ponding user group's workload is due to the l workload identified by workload pointer field 1786.
I As explained above, user groups are mechanisms which can be used to organize the sources of the workloads. Figure 18 shows an example of a user group data structure 1800 organized in a tree s~ruc~ure. The user group data structure 1800 includes a user group root node 1810, as well as nodes 1820-1840 corresponding to different user groups. In the ~ example shown in Figure 18, node 1820 corre~ponds to an engineering user group, node 1830 corresponds to a marking user group, and node 1840 correspond3 to administration uf2er ' group.
i The user group data structura includes a plurality of i third data entrie~ each correspondinq to a u~er group. The ~ user group data entries, or nodes, are similar to ~he generic 'I node 800, except that the user group nodes do not have a library pointer 830, a child list head 930, or a NSCP list I head 980. User group nodes also do not have a variant record in the preferred embodiment.
In Figure 17, user group node 1770 has a name field 1772, indicating the name of the corresponding user group, and an element type field 1777. User group node 1770 al80 ¦ include~ a parent poin~er 1775 to the model nods ~nd a , workload pointer 1774 to a linXed list for user group branch ~.~worrlcc~ 1, probabilities.
INNECA~. HE~DERSON
FAR.~BO~. GARRETT
~ DUNNER
1300 1 9TREET, N. W.
INOTON. 0C 2000~
~ ~ Ll 7 S, ;~
1 ¦ One of the entries in the linked li~t i~ user group branch probability node 1780. Branch probability node 1780 has a parent pointer 1782 identifying a linked list which , include~ workload node 1750. Branch probability node 1780 also includes a workload pointer 1786 identifying a linked list with workload node 1750. Workload node 1750 is in the ¦ workload linksd list for node 1780 because the user group ¦ corretponding to node 1780 contributes to the workload I corresponding to node 1750. Additionally, user group branch I probability node 1780 include~ a device pointer 1787 which ~i identifies the corresponding user group node 1770. This I pointer allow~ traver3al of the data ~tructure to find the I user group from the workload using ~he user group branching il probability nodes.
l User group branch probabLlity node 1780 also includes a ¦ float field 1784, a probability field 1~85, and a node type ¦ field 1788. Probability field 1785 indicates what percentage of the corre3ponding user group's workload is due to the l workload identified by workload pointer field 1786.
4. MSCP Data Structure.
Figure 19 shows a computsr system 1900 which uses the MSCP protocol. The computer system include~ an NI bus 1905 i to whic~ ar~ connected a CPUl 1910 and a CPU2 1920. CPU1 l 1910 i~ al~o connected to a di~k 1915, and CPU2 1920 i~ also 1¦ connected to a disk 1930.
.AW or~lc~ I I The MSCP protocol, which would be embPdded in ~oftware . INNECAN. HENDERSON, ~ D~;NNER . in CPUl 1910 and CPU2 1920, allow~ us~r~ of CPU1 1910 to 1300 t gTREET, N. W.
W~S~tINGTON. OC 2000~ j 1'202 401~-4000 -49-2 ~
1 ¦ access a file on disk 1930 without having to manage the communication between CPUl 1910 and CPU2 1920. If a user of CPUl 1910 requests to access of a file on a non-connected disk, CPUl 1910 is termed the ~source CPU. The dis~ which contains the file, in thi~i case disk 1930, is called ~he ~served~ disk. The CPU connected to the served disk, in this case CPU2 1920, is called the ~server~ CPU.
A preferred ambodiment of an MSCP tree 2000 is shown in Figure 20. MSCP tree 2000 does not correspond to system 1900 in Fig. 19. The preferred organization has the server CPU
being represented by node 2010. The possible source CPUs for the server CPU, source CPUl, source CPU2, and source CPU3, are represented by nodes 2020, 2030, and 2040, respectively.
The source CPU nodes are children of the i~erver CPU node.
I The ~erved disks are repre~ented as children of the source CPU nodes. ThuS, diskl is represented by node 2050 is a child of nodes 2020 and 2030; disk2 is represented by node 1 2060 which is a child of node 2030, and di~k3 i3 represented ¦ by a node 2070 i9 a child of nodes 2030 and 2040. This organization indicates that diskl can act a3 a served diCik i, for CPU1 and CPU2, disk2 can act as a served disk for CPU2, and dii~k3 can act as a served disk for CPU3 and CPU2. The relationship ~ui3t dei3cr;bed between eierv~d disks and ~ource I CPUs relates only to the server CPU represented by node 2010.
! Figure 21 shows the relationship between MSCP ~rees 2100 .AwO~rc~. j and 2105 and certain nodes of a de~ii-~s tree 2101. In Figure E(~ i. HE~DER50~;;
r~R&3D~ R ¦ 21, CPU-l is reprei3ented in davice tree 2101 a,~i node 2110, 1300 ~ gTl~ltEl', N.
l~NOTON. DC 2000 1 202 .~0~ 000 : I
2 ~ ~ 7'i~ J ''i ~
1 1 CPU-2 is represented as node 2113, and CPU-3 is represented by node 2118. Similarly, disk-1 would be represented in device tree 2101 by node 2120, disk-2 by node 2123, and disk3 ! by node 2128.
IMSCP tree 2100 contains a server CPU-l node 2130 which I corresponds to CPU-l node 2110 in device tree 2101. In MSCP
¦ tree 2100, the two source CPUs, E30urce CPU-2 and source CPU-¦ 3, are represented by nodes 2135 and 2140, respectively.
~ Source CPU-2 2135 correspondE3 to CPU-2 noda 2113 in device ~tree 2101, and source CPU-3 node 2140 corresponds to CPU-3 ¦ node 2118 in device tree 2101. Source CPU-2 node 2135 has as ¦ children served disks node~ 2143, 2148, 2150 and 2153. The ¦ correspondence between disks 2143, 2148, 2150, and 2153 and ¦ device tree 2101 is not shown in Figure 21.
ISource CPU-3 not only ha~ as children Qerved disk nodes 2150 and 2153, it also has as a child served disk node 2158.
Served disk node 2158 correspond3 to disk-3 node 2128 in device tree 2101.
MSCP tree 2105 is for CPU-3 as the server CPU. Tree 2105 therefore hae a s3rver CPU node 2160 aq a root. Server CPU-3 corresponds to CPU-3 nods 2118 in the device tree 2101.
The source CPUs in MSCP tree 2105 would be source CPU-2 node 2165 and source CPU node 2170.
l Source CPU-2 node 2165 corre3pond~ to CPU-2 node 2113 in , device tree 2101. The children of ~ource CPU-2 node 2165 are ~WO~C~- served disk-2 node 2173, served disk-3 node 2178, served disk .HENDERso~
8 D~:NNR ; nods 2180, and served disk node 2188. Served di~k-2 nod~
1300 I STREET. N. W.
WASIIINOTON. DC Z0005 I`202 .~01!1-~000 ~ ~ O l.~ 7 ~
1 1 2173 correspond~ to the disk-2 node 2123 in device tr0e 2101, and ~Qrved disk-3 node 2178 corresponds to disk-3 node 2128 in device tree 2101.
Il Source CPU node 2170 would have as children served disk I node 2183 and served disk node 2188. Disk nodes 2183 and 2188 would correspond to disks in device tree 2101, but that relation6hip is not shown in Figure 21.
In the preferred embodiment, a node of an MSCP tree ~ would resemble node 800 in Figure 8, and would have a variant ~I record 2200 as shown in Figure 22. The two subfields in variant record 2200 are MSCP 3erver pointer 2210 which identifi2s the MSCP tree for which the corresponding node is for a server CPU, and an M9CP device pointer 2220, which I¦ identifie3 the corre~ponding node in the device tree.
il The relation~hip between MSCP node~ and device nodes is ¦¦ shown in Figur~ 23 in mere detail. A device tree 2300 has a ¦I CPU node with an MSCP pointer 2310 in its varia~le record I¦ corre~ponding to the server CPU of a MSCP tree 2305, a CPU
¦¦ node with an ~SCP pointar 2340 in its link array identifying 1¦ a source CPU Ln MSCP tree 2305, and a di~k with an MSCP
pointer 2370 in its link array identifying a served disk in MSCP tree 2305.
I MSCP tree 2305 include~ server CPU MSCP ~ode 2320 with ~ an MSCP ~erv~r pointer 2322 which identifies the server node 2S ~11 2320, an MSCP device pointer 2325 which identifie~ the ~w or~cc~ 1I corre~pondLng CPU node in device tree ~300, and a child , INNEGAN HENDERSON I
~ D~NNER ' 1.
1300 I STl~EEr, N. W. I ' W~NOTON. O C ZOOO~ ¦
k'202 403-4000 ll -52-111 2 ~ r) r ~
1 1 pointer 2328 which identifies a linXed lis~ containing source CPU MSCP node 2330.
Source CPU MSCP node 2330 is a node pointed to by the Il MSCP link field 2340 and contains an MSCP server pointer 2332 , which identifies the server CPU MSCP node 2320 and an MSCP
de~ice pointer field 2334 which identifie~ the corresponding CPU node in device tree 2300. The parent pointer 2336 in ~I source CPU MSCP 2330 identifies the ~ervar CPU MSCP node ~l 2320, and child pointer 2338 identifies a linked list 1 containing disk MSCP node 2380 as a served disk for the ,¦ corresponding ~ource CPU.
,I The disk MSCP node 2380 is the node pointed to by the served disk NSC~ link 2370 from ~he device tree 2300 and Il contain~ an MSCP ~erver pointer 23~2 which identifie~ the ¦I server CPU MSCP node 2320, and an MSCP device pointer 2385 which identifies the corresponding di3k node MSCP in device tree 2300. Disk MSCP node 2380 also contains a parent pointer 2388 which identifies the source CPU MSCP node 2330.
C. Model Execut_on 1 Nith the undRrstanding of the data ~ructures presented above, a more detailed explanation can be given of how the different oparation3 are implemented using the data structures in data storage 315 and the elements of modeling interface 300 and 350 in Figure~ 3(a) and 3(b). The ¦ explanation which follow~ will usually refer ~u~ to the ~worrlec. elementY in Figure 3(a)/ but it ~hould be under~tood that for . I?;NEC~N. HENDE~50 ;.~R.~EO~'. G,~RRETT
~ DUNNER
1300 ~ 9TRrliT. N. W.
~IIINOTON. OC 2000~ 1 ~U~0~409-40oo !i _53~
Il 1,l , 2~737 ~3 1 the mo~t part the elements in Figure 3(b) will perform equivalently.
Eigure 24 includes a generalized flow diagram 2400 Il explaining how the modeling in~erface of this invention I reacts to inputs received from operators using modeling interface main menu 500 shown in Figure 5(a). The software ! for managing the display, the windows, and the cursor are well-known to persons skilled in the art. Preferably that Il software would be resident in display logic 322 and keyboard ll logic 323, although such software, or alternative means of i control such as microcode, PLA~, etc., could be implemented I¦ in a number of equivalen~ manners con~iisT:ent with the present il invention.
j' When main menu 500 i8 displayed, keyboard logic 323 wait~i for an operator input to designate the Relection of an ¦ option. When that input is received (Step 2410), a ¦I determination i~ made of tha type of input. If the FIhE
¦¦ option wa~i selected, then a FILE procedure is executed (Step Il 2420). If the S~T option is selected, a SET procedure is 11 executed (Step 2430). If the ADD option is selected, an ADD
¦ procedure i~ executed (Step 2440). If the DUPLICAT~ option i3 ~el~cted, a DUPLICA~E procedura (Stap 2450) i~i exscuted.
If the MOV~ option i8 selected, a MOVE procedurs i~i executed (Step 2460). If the REMOVE option i~i selected, a RE~OVE
¦¦ proceduro (step 2470) i~ executed. If the VIEW option i~
~worrlc~ !i selected, a VIEW procedure is executed (S~ep 2480). If the rlNNECA~I. HENDER50N ¦l FARABOW, CARRETT ~¦
DUNNER ¦ j 300 ~ 9T~ T, N. W. j NOTON. DC 20005 1 1 l Z02 ~0a-4000 '~
, I
i l SOLVE option is selected, ~ SOLVE procedure is executed (step 2490).
At the conclu~ion of procedures 24~0-2490, the di3play Il of display/keyboard 320 is updated as nece~sary (Step 2495).
S ~I For example, if the execution of one of the procedure~ caused I the display da~a to become stale, that data will then be displayed in bold text. After the display is updated, '1 control is returned to main menu 500 and Step 2410 to await .l another input.
1, 1. ~3 i; Figure 25 shows a flow diagram 2500 for implementing th~
FILE procedure 2420 in Figure 24. In the preferred ¦ implementation, the specific functions performed during the ~¦ FILE option are preferably implemented by parser3 310 and 34 i; in Figure 3(a), or by par~er~ 360 and 390 in Figure 3(b), although it i~ not crLtical to the pre~ent invsntion to have the parsers implementing these functions. These functions ~i could, for example, be implemented by other element~ by . I central software control.
¦ In flow diagram 2500, the operator i~ queried for an ¦ indication o~ the suboption de~ired. Upon receipt of an ¦ input from the keyboard specifying a type of input (Step ¦ 2510), a determination is made of the ~ype of input. If the j input indicates selection of the LOAD ~uboption, the operator I is queried for the name of the model file. When modeling ~AwOrrlccg !i interfacs 300 receive~ that name (Step 2515), ths model file FI~NECAN HENDER50N, ~DE;NNER l with the sp~cified fil~ name i8 loaded from th~ .MDL file 305 1300 I STREI!T, 1~. W.
W~9HINOTO~. DC 20009 ,20240~000 -55-2~ll7~3 ~ ' 1 1 into the modeling interface 300. Upon conclusion of the loading, ~he modeling session is continued.
If either the WRITE or EXIT suboptions were selected by I the operator, the current model is written to .MDL file 345 (step 2530). In the case of the ~RITE option, the modeling ;, session is continued (Step 2540). In the casa of the EXIT
option, the modeling session i~ ended (Step 2550).
¦ If the QUIT suboption is chosen by the operator, the I operator is then a~ked whether the current model file should I be written to disk (Step 2545). If the operator responds in the affirmative, the current model file is written to .MDL
Ij file 345 (Step 2530), and the modeling session is ended (Step il 2550). If the operator responds in the negative, the model I¦ se~sion i8 ended without writing the model file to .MDL file ~ 345 (Step 2550).
! 2. SET option Figures 26(a) and 26(b) show a flowchart 2600 containing ¦ the preferred implementation for executing the SET procedure , (Step 2430 in Figure 24). In the preferred implementation, 1 many of the functions perA~ormed in executing the SET
procedure are performed by di~play logic 32? ad~usting data in display context portion 318 (Figure 3(a)). Changer 330, on the other hand, perform~ the functions which involve either calculations or the ad~u~tment of ~he specific data 1 ~tructures in ~tructure context 317. The division of ~AW OrrlC~ I' re~ponsibilities among ~he different elements of modeling -INNEC~N. I!E~iDERS0N ' F.'~R~30W. G~RRETT
~!1 Li 1;~:~; E R
1300 ~ 9Ta~:~T, Y. W.
W~plNOTOY. OC 2000~;
~1~202-40_-4000 l -56-!l .1 1 7 ~
l ~¦ interface 300 and 350, however, are not critical to th~
¦¦ invention and could be accomplished in equivalent manners.
¦ In flow diagram 2600, when an operator has selected the ,I SET option, a menu is presented asking for a selection of a I suboption. In response, the opera~or supplies an input.
When that input is received, one of several actions will 'I occur.
i~ If the operator has selected the DISPhAY MODE suboption Il (Step 2610), then display/keyboard 320 presents the operator ~i with a menu asking for an indication of the display mode ¦ desired. When the desired display mode information i~
Il received from the operator (Step 2610), that information ls stored by keyboard logic 323 (Figure 3(a)) into display ¦ context data 318. Display logic 322 then uses the stored 1I information to con~rol the di~play of the information on ¦¦ display/k~yboard 320.
If the operator ha~ in4tead ~elected the CURRENT
WORKLOAD suboption (step 2610), the operator is ~ueried via a , menu whether to ~t the WORRLOAD or ~et the SOURCE CPU (Step ¦ 2620). If the op~rator wlshes to set the WORRLOAD, tha oparator i~ pr~s~nted with a menl~ to determine the idontification of the workload. Once the modeling interface 300 receives the workload identifica~ion (step 2622), that information is ~torsd by keyboArd logic 323 into the display context area 318 (Step 2625).
LAw~rr,cc, I~ the operator instead wishas to ~et the SOURCE CPU, FIN#ECAN HENDER50:~;
FARABOW. CARRETT
8 D1~NNER I the operator is requested, via a menu, to ~upply an 1300 1 5TREET, N. W.
WAg~llNOTON. DC Z000 I 20Z.-01~-~000 Il -57 ,1 ~ 0~ ~ 3"~ ~' l I identification of the SOURC~ CPU- When the modeling interface 300 receives that identification (Step 2627), l~ keyboard logic 322 stores that identification into display context portion 318 (Step 2628).
If, after selecting the SET option, the opera~or requested the BALANCE MODE suboption (Step 2610), the 1 operator is asked, via a menu, to indicate whe~her the operator wishes to balance the model or specify a balance ' mode (Step 2630). If the ~perator requests to balance the ll model, for example to ensure that all the branching l,, probabili~ies for each workload add to 100% (which may be il necessary depending upon the .MDL file received or becau~e of Il other changes made to the probability distributions), the ¦1 model i~ balanced IStep 2635), preferably by changer 330.
1l If operator in~tead wi~he~ to specify a balance mode, Ij the operator is asked to supply that balance mode, again i. using a menu in the preferred implementation. When modeling ¦l interface 300 receives the ~pecified balance mode (Step ! 2632), which can be either uniform or relative, keyboard il logic 323 ~tore~ that mode into display context portion 318.
I~, after selecting the SET option, the operator chooses the PROBABI~ITY DISTRlBUTION suboption (Step 2610), then the operator i3 queried~ via a menu as to the type of device for l which the probability distribution i~ being set (Step 2640 in 111 Figure 26(b)). The device type can either be a user group, a ~wor~lc~ CPU or a disk FI~EGANI, HE~DERSO~
FARABOW. GARRETT .
~S Dl~ IER .
1300 1 3TREET, N. W. .
WAS~IINOTON. DC 20003 j 3Ozoz 4o~ ooo ~ 58-20~J i-' 1 ¦ Next, the operator is presented a selection menu ! appropriate to the selected device type to identify a device ¦ and a workload for which the probability is to be set. When l¦ the operator selects the desired identification, the modeling ' interface receives the selection (Step 2642).
'¦ Next, the operator is pre~ented with a display screen il for input of the probabili~y distribution and other nece~sary ¦ data. The user supplies the probability distribution and ,I data, which can include information such as whether the ll probability distribution is FIXED or FLOATING. Once that I¦ information is received by modeling interface 300 (Step ¦¦ 2645), the probability distribution and data are stored by ¦¦ changer 330 in the node of workload trea 640 corresponding to ¦¦ the identified device (step 2648).
ll If the operator input in response to the main menu 500 !¦ was a request to set a WORRLOAD P~RAMETER (Step 2610), then iI the operator is presented a menu asking for a workload identification. When that identification i~ received (Step 2650), the operator iY presented a menu to supply an identification of ths workload parameters. When modeling interface 300 receives that identification, as well as the value~, from the operator (step 2655), changer 300 stores those workload parameters into the appropriate workload node in stru~ture context portion 317 (Step 2658).
If the operator reque~ts the SYSTEM LOAD option after ~worrlcc~ selecting the SE~ option from main msnu 500 (Step 2610), the Fl~:~ EC~;. HE~IDERSON
r~R~DW,~ERRRETT operator i~ presented a menu a~king for an identification of 1300 1 9rREEr. N. W.
W~g~lN irON. DC 2000 _59_ Il .
~ 7 j3ij ~
1 ¦ the load type (expressed in TPS) and percen~ag2 change (Step 2660). Whether the percentage change is positive or negative ¦ also indicates whether the change is an increase or a , decrease in the load.
,j The operator is then presented with a menu indicating whether the change i~ for a single workload, a user group, or ! for all of the workload~. If the oparator indicates that the i change should be for a single workload then the operator is ~I presented with a menu asking for an identification of the 1 desired workload. When that identification i~ received (Step 2662), changer 330 increase~ or decrease~ the identified workload by the indicated percentage (Step 2665).
~Ij If the opera~or in~toad indicate3 that the load type to il be changed i8 for all of the workload~ in a user group, then i the operator is pre~ented with a menu asXing for an ; identification of a user group. Once that identification is i received (Step 2663), changer 330 acce~e3 all of the workloads to which ~he indicated user group contributes, and !! ad~uits the workloadi3 by the indica~ed percentage 'I proportionate to the identified usar group~i3 contribution to the workload (Step 2666).
the operator in~tead indicates a desire to change all of th~ workloads, ~hen the TPS for all of the workloads are changed by ~he indica~ed percenta~e IStep 2667~. This i~
1, preferably al90 accompli~hed by changer 330.
~AW O~IC~ i Returning to Fi~ure 26(a), if the operator select~ the FINNECAN. HENDER50N 1 FARA~ D~NER I SET Ob~ect Nam~ iuboption, the oper~tor i3 presented with a 1300 I ST~ 7, N. W. i, WAglllN070N. DC 20005 j.
-0~000 ~ 60-li l l ~ 7 3i~s 1 series of menus asking for an identification of the ob~ect.
When the operator selects the identification of the ob~ect ! from the menu, and that selection is received (step 2670), Il the operator is pre~ented a window asking for the name of the ¦ device. ~hen the object name is received (Step 2675~, ;I changer 330 stores that name into the name field (see field ,l 810 of Figure 8) of the node associated with the indicated ;I device tStep 2678).
,1 If the operator has selected the SET Ob~ect Type option i¦ from main menu 500 (Step 2610), the operator is presented i with the series of menus explained previou~zly regarding the I SET Ob~ect Name option to identify the ob~ect. When the !~ identification of the ob~ect i~ received (step 2680), the ¦¦ operator i8 pre~ented with a menu a~king the operator to lli identify the ob~ect type desired. Once this identification is received by the modeling interface (Step 2685), changer 330 stores that ob~ect type in the element type field (see field ii 850 in Figure 8) for the identified ob~ect (Step 2688).
I At the end of the steps in S~T option flowchart 2600, ! control is returned to main menu 500 in Figure 5(a).
3. ADD oPtion If in~tead of the SET option, the operator had cho~en the ADD option from the main menu 500, then ADD procedure 2440 (Figure 24) would be executed. A preferred jl implementation of ADD procedure 2440 i3 shown by flow diagram ~w o rlc~ 1! 2700 in Figuro 27.
E~AN. HENDERSO~: !
F.~L~aOW. G~RRETT ~1 ~I DIJNNER
1300 1 3TQ~ , N W, ~III~IOTON. OC 2000 U ` Z02 - 0~- 4000 Il -61-i' I, ~ O l~
It should be noted, that for the ADD procedure 2440, as I¦ well as for DUPLICATE procedure 2450, MOVE procedure 2460, .¦ and REMOVE procedurP 2470, the changes ~o da~a structure 315, particularly structure con~ext 317, are preferably accomplished by changer 330. In other implementations, however, other elements can be u~ed to effect the changes to the data structure 315.
In flow diagram 2700, the operator i8 first presented ~ with a series of menus for the operator to identify the type 'l of ob~ec~ to be added (Step 2710). Once that identification is received (Step 2710), the operator is presented with a ~j menu to ~upply ~he noda parameter3 for the identified ob~ect.
¦I When tho~e node parameters are recelved (Step 2720), the ,¦ operator is presented with menu~ to specify the destination ¦ of the ob~ect to bs added. For exampla, if the ob~ect to be added i5 a disk, the operator will be asked to specify whether the di k i~ to be added to an HSC channel or to a ll CPU, and then iden~ify the specific HSC channel or CPU. If l! the ob~ect to ba added i8 an HSC or a CPU, the operator will ! be asked to identi y a bus adaptor which will indicate the I bus to which the device i~ added. In tha preferred implementation, an HSC or CPU will be added to the current bus, and must be moYed using the MOVE option if thi~ is not the desired destination.
l Once the location i~ recei~ed (Step 2730), the changer ~worrlcc~ il cr~ate~ a node with the parameters and adds it to the tree in FINNEGAN HENDERSO~ 11 FARA~DUNN~ERRRETT ¦¦ ~trUCtUre contsxt portion 317 a~ the appropriato location 1300 ~ S7REET, N. w.
W~9~11NOTON. DC 2000~ ¦1 I 202 ~0 S- 000 1 --62--Il ~ J~
1 ll (Step 2740). Note that the addition of an ob~ect will likely affect the displayed data which will become stale.
Control is then returned to main menu 500.
I 4. DUPLICATE oPtion , If the operator had chosen the DUPLICATE option from main menu 500, DUPLICATE proceduxe 2450 (Figure 24) would be executed. A preferred implementation of ~he DUPLICATE
I procedure i~ chown by flowchart 2800 in Figure 28. In i flowchart 2800, the first step is to identify the node to be I duplicated, which is done in the manner de~cribed above.
Once the node identification i8 received by modeling int0rface 300 (Step 2810), the identified device is duplicatsd by copying th~ node for the indicated device ¦ exactly, and then adjusting certain of the linked list-~ to Il add the device in the model next to the davice copied (Step I¦ 2820). In the preferred embodiment, however, the MSCP and ¦¦ workload information is no~ copied for new devices. Control iR then returned to the main menu 500.
l 5. MOVE option If the operator choo~es the MOVE option from main menu 500, ~OVE procedure 2460 (Figure 24) i8 executed. The preferred implementatLon of MOVE procedure 2460 is shown by flow diagram 2900 in Figure 29.
At the out~et of flow diagram 2900, the operator ic prompted by a menu ~o indicate whether the ob~ect to be moved ~worrlc~ I i~ a workload or a device. When the operator make3 that FINNECA~. HEN5ERSON ¦
1~ DUNNER j 1300 1 3T~EET, N. W
a~l~INGTON. OC 2000~S
JV, zoz 40e-4000 i -63 .1 ~¦ 2 ~3 ~
1 ~ indication, it is received by modelin~ interface 300 (Step 2910).
I~ the operator indicates that a device is to be moved, l¦ then a series of menus are presented for the operator to 1 identify the device. When that identification i5 received by modeling interface 300 (Step 2915), the operator is prompted by another series of menu~ to identify the destination of the 1 identified device.
¦ Once the destination is received by modeling interface ll 300 (Step 2920)l changer 330 removes the node for the i identified device from its curran~ location and inserts it into the device tree structure 700 at a po~ition i! corre~pondinq to the de~tination (Step 29~5). Thi~ procedure ¦¦ involves, among other funstions, reconnection of the parent l¦ linked lists in structure context portion 317 to indicate j movement of the corre3ponding node. The data structure~ for Il the model node are alqo updatad to reflect the movement of ¦ the node.
Il Once ~tructure context portion 317 i updated by changer 330, control i~ rsturned to main menu 500.
If, after 3electing the ~OVE optlon, the operator had instead chosen to move a workload, the opera~or i5 pre ented with ~ ~eries of menu~ to identify the workload and indicate whether the identified workload i~ to be moved from a CPU or i di~k. When thi~ inform~tion i~ recaived by modeling so~ interface 300 (Step 2930), modeling interface 300 next ;.~R.~90W. G~RRETT
g Dl!~J~;ER
~00 1 iT17CCT, N. W
~II~OTOt~. DC ~0005 ~
202 400'1000 11 ~I -64-l 2 '~3 ll 7 ~3~ ' de~ermines whether the node type i~ a CPU or a di~k (Step ! 2935 ) .
If the node type is a CPU, then the operator is presented with menus to identify source CPUs of the workload, the destina~ion CPUs of ~he workload, and the percentage of the workload to be moved. When this information ~s received :. (step 2940~, the CPV load i~ redistributed by moving the indica~ed percentage of the identified workload to the . de3tination workload (i.e., those which are already supporting that workload and whose probabilities are not .l already fixed) according to the balancing mode ~S~ep 2950).
¦ An example of how this might be done i8 shown in Figure 30. In Figure 30, 50% of workloadl is to be moved from CPU1 ¦ to CPU2 and CPU3. Bsfore ~he move, the branching pxobability for CPU1 is 25~, the br~nching probability for CPU2 i~ 35~, I and the branching probability for CPU3 i~ 40%.
After the move, 50~ of workloadl will have been taken from CPU1, ~o the remaining branching probability for CPU1 would be 12.5~. If a uniform balancing mode was cho~en, then the amount of the workload taken away from CPU1, or 12.5~, . would be ~h~red among CPU2 and CPU3. Thu~, both CPU2 and CPU3 would gat 6.25~, resulting in a branching probability for workloadl of 41.25% for CPU2 of 46.25~ for CPU3. This i~
repxe~ented by the leftmost number in the parenthesis in the 'I AFTER column in Figure 30.
,~E~A~HE~DER50N,I If a relative balancing mode is cho3en, then the ratio FARABOW, GARRETT I i ~Du~ER .1 of the balanclng probability for CPU2 and CPU3 must fir~t be 1300 1 5T`~EET. N. W. :
~VASNINOTON. DC 20005 , i 65-I 1l .
Ll 7 determined. One way of accomplishing thi5 i9 to add the branching probabilities of the affected CPUs for the identified workload and then determine the ra~io of each affected CPU to the sum. The ratio will not only be the percentage of the branching probabilities of CPU2 and CPU3 before moving the workload, it is also used to determine the amount of the moved workload which each CPU should receive to maintain the samo ratios.
Using this calculus, CPU2 has a ratio of 35/75 or about 47~, and CPU3 has a ratio of 40/7S or about 53~. Thus, 47~
of the change in CPUl's branching probability for workloadl, or 47~ of 12.5~, would be add~d to CPU2~s branching probability for workloadl and 53% of 12.5% would be added to CPU3's branching probability for workloadl. The re~ult would be that CPU2 would have 40.83% as its new branching probability and CPU3 would have 46.67 a~ its new branching probability. These are shown by the rightmost value~ in the parenthesis in the AFTER column for CPU2 and CPU3 in Figure 30.
Preferably, this calculation would be done by changer 330 in Figures 3(a) and 3(b), although it i~ not important to the pras2nt invention which element i9 performing tha calculation~.
After the workload~ are redistributed by percentage, modeling interface 300 determines whether any o~ the destination CPU~ are new participantq in thi~ workload (step . I~NEC\N, HENDER50N
~AR~80W, G~RRETT
:~ D~:NNER
1300 ~ 3TRU T, '1. W.
WA'.IIINOTO~.l. OC ZOOO~
1 202 ~0~ 000 -~6-3 ll 7 .~ ~ ~
¦ 2955). If not, or after the creation of the disk branching ¦ probabilities, control is returned to main menu 500.
If ~o, then a new CPU branching probability node has to be created to reflect the newly computed branching probabilities (Step 2960). The new branching probability node must be set with a value that reflects the redistributed percentage. For example, a~sume that prior to moving a workload, the following condition existed:
Svstem Load Diskl Disk2 CPU1 20% 80~ 20~
CPU2 80% 10% 90%
CPU3 0~ o%
If 50~ of the workload is moved from CPU1 and CPU2 onto CPU3 t the result would be: -Svstem Load Di~kl Disk2 CPU1 10% 80% 20 CPU2 40~ 10~ 90%
. CPU3 50~ 24% 76%
.' The load for di~kl is obtained by taking the percent of the j load on diskl from CPU1, or 20% x 80~, and adding it to the ¦ percentage of the workload on diskl form CPU2, or 80% x 10~.
'¦ The re~ulting 8um iS 24%. Similarly, if the load for disk~q ! from CPUl~ or 20~ x 20~ is added ~o the percen~. of the worXload in disk2 on CPU2, or 80% x 90%, the sum i 76%, which i a percentage of the workload shown in CPU3 for ~AW orrlc ~ l, q ::NNEC~N HENDERSON
F~R.~90W. CARRETT
1~00 1 5TR'Er~ N. W.
~WOT0R. DC Z0005 I`Z02 ~01~-4000 , , ~, ,~1 5~ a ~1 7 j ' ¦ If the workload to be moved is from a disk, then the ¦ operator is presented a series of menus asking for an identification of the source CPU nodes for the disks. When this identificaTion is received (Step 2970), the operator is then asked, via other menus, to identify the source disks of ; the workload, the destination disks of the workload, and the percentage of the workload to be moved. When this identification is received (Step 2975), the workload~ are redis~ributed by percentage (Step 2980). Preferably, this involves reducing the percentage of the load from all of the source nodes, and increasing the percentage of the load to all of the deitination nodes according ~o the balancing mode . in the same manner as is done when a CPV load is moved.
After redistribution of the workloads, control is returned to main menu 500.
6. RENOVE o~tiQn If operator had selected to REMOVE option from main menu 500, then RE~OVE procedure 2470 (Figure 24) i9 executed. A
preferred implementation of REMOVE procedure 24~0 is shown by flow diagram 3100 in Figures 31(a), 31(b) and 31(c).
. In flow diagram 3100, the operator is first presented I with a menu to determina the type of ob~ect to be removed l ( St8p 3110). If the operator respondis by identifying a I device, ~he operator is preiented with a menu as~ing for an :l identification of the specific device to be removed, and tha~
~W O~IC~9 ~ identification is received by the mo~eling interface ~Step -INNECAN. HENDER50N
FARA30W. GARRETT
j3 DUNNE~ I 3112 ) .
1300 ~ gl'Q~T, N. ~q, !
WA~I~IN31'C1N, OC Z000~ !
I Z02'-09-4000 , -68-.1 2 ~
~j If the operator identifie~ a CPU, then changer 330 first deletes ~he child nodes o~ that CPU (Step 3114). The deletion of the child nodes, such as disks, is di~cussed below .
Next, changer 330 deletes the ~SCP source CPU node~
(Step 3116). The source CPU nodes can be located using the MSCP linked list for the corresponding node. Deletion of the source node~ also daletes the served disk nodes that were its children, requiring further modification of device tree 700 and MSCP tree 660 as appropriate.
Next, the corre~ponding sen~er node MSCP sllbtree for that node i~ deleted if one is pre~ent ( Step 3117 ) . The tree can be found using the MSCP pointer 1310 (Figure 13 ~ of the device node. Thi~ deletion will alRo have ramifications on all the device nodes corresponding to source CPU nodes or served disk nodes for the delsted MSCP tree, and must be handled appropriately.
After deletion of the MSCP server nodes, the CPU branch probabilities for each workload supported by the identif ied CPU must be rebalanced f or the remaining CPUs ir~ accordance with the balance mode (step 3118). The details fer such , rebalancing was de~cribed above in the explanation of the MOVE: f low diagram 2 9 0 0 .
Next, the nodes for each of the adapters for the CPU are i deleted (Step 3119). Thi~ effectively disconnects the AwO,rc~, deleted CPU nodes from the bu~es.
F.'~R.~30W. G~RRETT
1~00 I ST1111~T. N. W.
~1NOTON~ OC 20Q0 1 20i~ 40~ 000 5~ ; fjl 'c~
The final step in removing a CPU node i~ the deletion of the stati~tics list and the deletion of the node itself (Step 3120). After that, control is returned to main menu 500.
If the type of node to be removed is a disk, or if a disk is to be deleted as part of the removal of a CPU, the MSCP served disk nodes are deleted (Step 3130). Such nodes can be located by the MSCP linked li~ts for the node corresponding to the disk to be deleted. The deletion of a disk node from the MSCP tree involves the ad~ustment of the MSCP ~ubtree~ as well to eliminate any pointer~ to the deleted disk.
AftPr deletion of the MSCP di~X nodes, the disk branc'n probability nodes for the iden~ified di~k are deleted by changsr 330 (Step 3132). Such probability node~ can be identified using the workload linked lists for the node corresponding to the identified dis~.
Noxt, the disk branch probabilities for each workload , that was supported by the identified disk are rebalanced j (Step 3135). Again, this rebalancing i8 performed ~eparately 'j for each workload~ and i8 done in accordance with the '. identified balancing mode.
The final ~tep in the removal of a disk is the deletion of the ~tatistic~ li3t, if present, and the deletion of the I di~k node it~elf (Step 3120). When this i8 done, control is Awo~rlcc~ I returned to the main menu 500.
I~NECAN HENDERSON
FARA30W. GARRE~T
~ DUNNER ~ !
1300 I Srl~l~ET, N. W, WA9NIli0TON. DC 2000!1 I 20Z - ~0 9 - ~00 0 2 ~ ll I r,j ~ -,¦ If the device to be removed has been identified by the operator as something other than a disk or CPU, such as an HSC, changer 330 first deletes any child nodes whose only parents are either the ob~ect to be deleted or a child of an object to be deleted that doeR not have a parent which survive~ the deletion (Step 3140). For example, if an NI bus were deleted, CPUs that still were connected to a CI bus ; would not be deleted, nor would the di~k~ connected to that CI bus. All CPUs connected only to the NI bu~, however, would be deleted, a~ would any devices connected only to those CPU4. The deletion of CPUs and disks ha~ been described above.
For the child nodes that have more than one parent, their parent linked li~ts ar~ ad~usted to reflect the absence of the parent which is being dele~ed (Step 3142).
Finally, the node for the device to be deleted is itself deleted (Step 3120). If the node has a statistics list, it is deleted. Control i3 ~hen returned to the main menu.
If the operator i~ using ~he REMOVE option to delete an ! MSCP elemant, the ~tep~ shown in Figure 31(b) are executed, preferably by changer 330. The first datermination made i~
what the tyye of device i~ to be deleted from the ~SCP
,¦ element (S~ep 3150). Thi3 iY preferably done using a menu.
If an MSCP servsr CPU node i~ to be dele~ed, the node in the MSCP tree for the qerver CPU to be deleted is acces~ed by changer 330 (St~p 3151). Thi~ is preferable done through the -INNEGAN. HENDER90N
FARA90W. GARRETT
~D~NNER MSCP pointer 1310 (Fi~ur~ 13) of the d~vice nod~.
1300 ~ 9Ti~EET, N. W.
WAS/lWOTO~ . DC 20003 1 202 ~01!1 ~000 ~ ~) Ll r~
Once the MSCP node is accessed, the source nodes in the trees are decoupled from the CPU device node (Step 3152).
This i3 accomplished by changer 330 in the preferred implementation by adjusting the MSCP linked lists for the CPU
nodes. The source CPU MSCP nodes for the ~SCP tree are then deleted (step 3153).
Next, the disk device nodes in the MSCP tree are decoupled from the nodes in device tree 700 (Step 3155). The device tree nodes can ba located u3ing the disk MSCP
pointers, such as pointer 2382 in Figure 23. Decoupling involves adjustment of the MSCP linked lists of the nodes in device tree 700 for the corre~ponding disks. After decoupling, the disk CPU ~SCP node~ are deleted (step 3157).
Finally, the server CPU NSCP node is deleted (Step 3158). Such deletion is accompanied by the clearing of the MSCP pointer 1310 (Figure 13) in the corre3ponding device tree node. Control i~ then returned ~o main menu 500.
If one or more source nodes are to be removed, the ~ corresponding server CPU node is acces~ed tStep 3160), and I from that access, the designated source CPU nodes are acces~ed (step 3162).
Next, the sourca CPU nodes are decoupled from the i corresponding C~U device node by corrsc~ing the linXed list~
accordingly (Step 31b5). Then the source CPU NSCP nodes are I deleted from the MSCP trees for tho corresponding ~erver node .AwOrr.ce~ (Step 3168). Control i~ then returned to main menu 500.
!~;EC~. HE~DER50~ ¦
F.~R.~30W GARRETT
~ DU~;~ER ~;
~:100 I S~T~T, . ~'1. !
5111N /SON. I~C 2000 I `202'400'.-000 2~1~7~7; :.~
If a disk is to be removed from an MSCP relationship, changer 330 accesses the corresponding server CPU MSCP nodes (Step 3170), source CPU MSCP nodes (step 3172), and disk MSCP
nodes (Step 3175). This access is preferably done by locating the proper MSCP trees.
After the disks are acce~3ed, the corresponding di~k device nodes in device tree 700 are decoupled from the NSCP
tree (Step 3178), and the disk MSCP nodes are deleted (step 3179). When this is finished, control is returned to main menu 500.
; Returning to Figure 31(a), the operator could also choose to delete a user group. If ~o, the preferred implementation step for such a choice are shown in Figure 31(c).
The operator i8 fir~t presQnted with a window asking for . an identification of the u~er group to be removed. When the operator makes tha choice, changer 330 identifies the corresponding user group nodes (Step 3180).
Once the user group node i~ identified, changer 330 j deletes the workload branch probability nodes for that u~er group (St~p 3182). Tho workload pointer~, such as pointer . 1774 in Figure 17, can be u~ed to find the needed user group branch probability node After deleting the branch probability node~, changer 330 . rebalanceg the other user group~ branch probability nodes F NNE~N HENDERSON according to th~ balancing mode (Step 3185). If a user group FAR~BOW, CARRETT
h Dl,~JNER
1300 I STR~CT, IJ. W.
WA9~ 0T0-~. DC Z000 I 202 ~011 ~000 7 ~
wa5 respone~ible for 100% of any workload, that workload is also delated.
Once this is done, the node for the user group i~
i deleted (Step 3199). Control is then returned to main menu 500.
If the operator chooses to remove a workload, then the i operator is presented with menus to select the workload to be ! removed. Once the workload i~ identified, changer 330 finds the workload node associated with that workload (step 3190).
Next, changer 330 delete~ all disk branch probability ~ nodes for that workload (Step 3132). This i~ ea~ily ¦ accomplished using the tree structure for the workload tree.
'I Next, changer 330 deletes the workload CPU branch I probability nodes (Step 3195). Thi3 too i8 accomplished ¦ easily by virtue of the workload tree's structure.
Next~ the user group branch probability nodes for the identified workload are deleted (Step 3~97). Thi3 too makes use of the structure of the workload tree in the preferred implementation.
i ~inally, the statistic block~ for this workload in each I devico'~ qtatistic~ list are deleted (step 3198).
When all these tasks have been completed, ~he node for ! the corresponding workload i~ deleted (Step 3199). Con~rol . i8 then returned to the main menu 500.
7. VIEW_o~tion If, in flow diagram 2400, the operator had chosen the ;EC~;. HE~;DERSO~;
F.~R.~BO~ GARRETT
3 D~ER VIEW option, then VI~N procedure 2480 would be implemented.
~300 1 ST ;~r, N. ~.
~9~1NOTON. DC 2000~ ¦
, ~02 -03-4000 :I
''I
!
S~il 7~, `
¦ Figure 32 contain~ flow diagram 3200 showing a preferred implementation of view procedure 2480.
In flow diagram 3200, the operator is presented with a I menu a~2king for an identificatian of the device type. When the operator makes a selection and it is received by modeling interface 300 (Step 3210), the operator is presented with a series of menu~ to identify a ~pecific device. When modeling interface 300 receives the operator~s identification of a device (Step 3220), display logic 322 creates the desired zoomed view (Step 3230). This involves the application of display techniques which would be known to persons skilled in the art, and thus does not need to be de~cribed further.
After creating the desired view, the control i~ returned to main menu 500.
8. SOLVE o~tion The rsmaining option which an operator could select from the main menu 500 i3 the SOLVE option. If that option is chosen, then SOLVE procedure 2490 is executed. Preferably, procedure 2490 i~ executed by solver 335 in Figures 3(a) and 3(b).
The preferred implementation of solver 335 is described in detail in U-S.S-N. 07/280,171 to Kwaq et ak , which i~
herein incorporated by reference. Kwaa et al. de cribes a device for taking information de~cribing a computer ~y~tem, generating a mathematical model of the computer system, and .AwOrrl~c. ; evaluating result~ u3ing ~he computer 3ystem ststi~tic~.
INNE(;AN~ HENDRSON
F.~R.~30W. G~RRE~
5 D~NNER
1300 1 57R~I~, N~ W.
WA~lllNOrON~ DC Z000~1 ` 202 oa - Aooo ~3Ll7~, ~
In the preferred implementation of the invention, solver ¦ 335 retrieves the data from data storage 315 (Step 3310).
Preferably, solver 335 would have code for retrieving the configuration data directly from the tree structures in data storage 315. Retrieval of data from trees is well known to persons of ordinary skill in this art.
If, however, solver 335 is designed to retrieve data in an array format, then a parser, such a~ parser 390 shown in Figure 3(b), can be used to convert the data from a tree structure into an array structure for use by solver 335.
I Once the data is retrieved, ~ol~er 335 determines new i metrics ba~ed upon a mathematical model of the computer system configuration (Step 33~0). The metrics include information such as queue length~ and delays in the system.
When solver 335 complete~ it~ calculations, it writes those new metrics into the da~a structure 315 (Step 3330).
Again, in the preferred embodiment, the metrics would be written directly back into the device, workload, and user group tree ~tructures. Solver 335 could also place the metric~ data into an array structure. In this case, parser 390, as well as par~er 365, both shown in Figure 3(b), could be u~od to place the new metrics values into the appropriate tree ~tructure~.
When ~olver 335 comple~e~ it~ calculations and storage ¦ of data, control i~ returned to main menu 500.
.~wOFrcc, l D Parser INNECAN HENDERSON
FARA30\1V. CARRETT
~I Dl,'NNER
1300 I STF~En~ . W. I
W~5~1~'10T0~. C)C Z0005 I Z02 ~0 1-. 000 i t~ r Y J ~7 ,1 il The only elements of modeling interfaces 300 and 350 ¦ that hsve not been discussed in greater detail are the parser~, such as parsers 310, 340, 360, and 390, and interface 365. Parser construction is generally known to persons skilled in the ar~, especially when providing an interface to tree structures and linked lists.
Figure 34 shows thc format 3400 for the .MDL files 305 ; and 345. Parsers 310, 340, 360 and 390 wo~ld then be designed to provide an interface for such format~, or for any other format used in an implementation of the invention.
E. Summarv From th2 preceding explanation it can be seen how the modeling interface of thi~ invention achieves the desire~ set forth. This invention prov.ides a mechanism for performance analysis and capacity planning that allows for a more meaningful presentation of performance information. It does I so using the displays and menu~ de~cribed above.
! The present invention also provides an improved I mechanism for changing the configurations of the computer i system, at least in a virtual ense, to detenmine the effects of ~uch changea. That improved mechani~m includes the di~play of the computer system configuration as well as the di~play of the selected metrics with that configuration.
Similarly, the precent invention provida~ an improved mechanism for pre enting the effect~ of the changes in FI~E~HrE~'D'ER50~i configuration in a manner which allows ready deci~ion making.
F.~RA30W. G~RRETT
.~Du~ER The display discussed above provides a meaningf~Al 1300 ~ STqEET. N. W.
1 20~ 409--000 1 r~ r j ~
presentation of changes to a computer system being modeled to enhance capacity planning and p~rformance analysis.
I The foregoing description of preferred implementations I of the invention has been presented for purposes of illustration and description. It i~ not intended to b~
exhaustive or to limit the invention to the precise forms disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiments were chosen and described to explain the principles of ~he invention and its practical application to enable one skilled in the art to use ~he invention in variou embodiments and with various modifications as are ~uited to tho particular u~e contemplated. It i~ intsnded that th~ scope o~ the invention be defined by the appended claims and their equivslents.
i i .
L~W orrlc~
:I~;NEC~;, HE~DERSO~: ¦
F~R~30~. CARRET~ ;
~S) DllN~:ER
11100 I STi~T, N. W.
W~g~NOTON. DC ZOOO~
,202.0~000 1 ~78-.1
Figure 19 shows a computsr system 1900 which uses the MSCP protocol. The computer system include~ an NI bus 1905 i to whic~ ar~ connected a CPUl 1910 and a CPU2 1920. CPU1 l 1910 i~ al~o connected to a di~k 1915, and CPU2 1920 i~ also 1¦ connected to a disk 1930.
.AW or~lc~ I I The MSCP protocol, which would be embPdded in ~oftware . INNECAN. HENDERSON, ~ D~;NNER . in CPUl 1910 and CPU2 1920, allow~ us~r~ of CPU1 1910 to 1300 t gTREET, N. W.
W~S~tINGTON. OC 2000~ j 1'202 401~-4000 -49-2 ~
1 ¦ access a file on disk 1930 without having to manage the communication between CPUl 1910 and CPU2 1920. If a user of CPUl 1910 requests to access of a file on a non-connected disk, CPUl 1910 is termed the ~source CPU. The dis~ which contains the file, in thi~i case disk 1930, is called ~he ~served~ disk. The CPU connected to the served disk, in this case CPU2 1920, is called the ~server~ CPU.
A preferred ambodiment of an MSCP tree 2000 is shown in Figure 20. MSCP tree 2000 does not correspond to system 1900 in Fig. 19. The preferred organization has the server CPU
being represented by node 2010. The possible source CPUs for the server CPU, source CPUl, source CPU2, and source CPU3, are represented by nodes 2020, 2030, and 2040, respectively.
The source CPU nodes are children of the i~erver CPU node.
I The ~erved disks are repre~ented as children of the source CPU nodes. ThuS, diskl is represented by node 2050 is a child of nodes 2020 and 2030; disk2 is represented by node 1 2060 which is a child of node 2030, and di~k3 i3 represented ¦ by a node 2070 i9 a child of nodes 2030 and 2040. This organization indicates that diskl can act a3 a served diCik i, for CPU1 and CPU2, disk2 can act as a served disk for CPU2, and dii~k3 can act as a served disk for CPU3 and CPU2. The relationship ~ui3t dei3cr;bed between eierv~d disks and ~ource I CPUs relates only to the server CPU represented by node 2010.
! Figure 21 shows the relationship between MSCP ~rees 2100 .AwO~rc~. j and 2105 and certain nodes of a de~ii-~s tree 2101. In Figure E(~ i. HE~DER50~;;
r~R&3D~ R ¦ 21, CPU-l is reprei3ented in davice tree 2101 a,~i node 2110, 1300 ~ gTl~ltEl', N.
l~NOTON. DC 2000 1 202 .~0~ 000 : I
2 ~ ~ 7'i~ J ''i ~
1 1 CPU-2 is represented as node 2113, and CPU-3 is represented by node 2118. Similarly, disk-1 would be represented in device tree 2101 by node 2120, disk-2 by node 2123, and disk3 ! by node 2128.
IMSCP tree 2100 contains a server CPU-l node 2130 which I corresponds to CPU-l node 2110 in device tree 2101. In MSCP
¦ tree 2100, the two source CPUs, E30urce CPU-2 and source CPU-¦ 3, are represented by nodes 2135 and 2140, respectively.
~ Source CPU-2 2135 correspondE3 to CPU-2 noda 2113 in device ~tree 2101, and source CPU-3 node 2140 corresponds to CPU-3 ¦ node 2118 in device tree 2101. Source CPU-2 node 2135 has as ¦ children served disks node~ 2143, 2148, 2150 and 2153. The ¦ correspondence between disks 2143, 2148, 2150, and 2153 and ¦ device tree 2101 is not shown in Figure 21.
ISource CPU-3 not only ha~ as children Qerved disk nodes 2150 and 2153, it also has as a child served disk node 2158.
Served disk node 2158 correspond3 to disk-3 node 2128 in device tree 2101.
MSCP tree 2105 is for CPU-3 as the server CPU. Tree 2105 therefore hae a s3rver CPU node 2160 aq a root. Server CPU-3 corresponds to CPU-3 nods 2118 in the device tree 2101.
The source CPUs in MSCP tree 2105 would be source CPU-2 node 2165 and source CPU node 2170.
l Source CPU-2 node 2165 corre3pond~ to CPU-2 node 2113 in , device tree 2101. The children of ~ource CPU-2 node 2165 are ~WO~C~- served disk-2 node 2173, served disk-3 node 2178, served disk .HENDERso~
8 D~:NNR ; nods 2180, and served disk node 2188. Served di~k-2 nod~
1300 I STREET. N. W.
WASIIINOTON. DC Z0005 I`202 .~01!1-~000 ~ ~ O l.~ 7 ~
1 1 2173 correspond~ to the disk-2 node 2123 in device tr0e 2101, and ~Qrved disk-3 node 2178 corresponds to disk-3 node 2128 in device tree 2101.
Il Source CPU node 2170 would have as children served disk I node 2183 and served disk node 2188. Disk nodes 2183 and 2188 would correspond to disks in device tree 2101, but that relation6hip is not shown in Figure 21.
In the preferred embodiment, a node of an MSCP tree ~ would resemble node 800 in Figure 8, and would have a variant ~I record 2200 as shown in Figure 22. The two subfields in variant record 2200 are MSCP 3erver pointer 2210 which identifi2s the MSCP tree for which the corresponding node is for a server CPU, and an M9CP device pointer 2220, which I¦ identifie3 the corre~ponding node in the device tree.
il The relation~hip between MSCP node~ and device nodes is ¦¦ shown in Figur~ 23 in mere detail. A device tree 2300 has a ¦I CPU node with an MSCP pointer 2310 in its varia~le record I¦ corre~ponding to the server CPU of a MSCP tree 2305, a CPU
¦¦ node with an ~SCP pointar 2340 in its link array identifying 1¦ a source CPU Ln MSCP tree 2305, and a di~k with an MSCP
pointer 2370 in its link array identifying a served disk in MSCP tree 2305.
I MSCP tree 2305 include~ server CPU MSCP ~ode 2320 with ~ an MSCP ~erv~r pointer 2322 which identifies the server node 2S ~11 2320, an MSCP device pointer 2325 which identifie~ the ~w or~cc~ 1I corre~pondLng CPU node in device tree ~300, and a child , INNEGAN HENDERSON I
~ D~NNER ' 1.
1300 I STl~EEr, N. W. I ' W~NOTON. O C ZOOO~ ¦
k'202 403-4000 ll -52-111 2 ~ r) r ~
1 1 pointer 2328 which identifies a linXed lis~ containing source CPU MSCP node 2330.
Source CPU MSCP node 2330 is a node pointed to by the Il MSCP link field 2340 and contains an MSCP server pointer 2332 , which identifies the server CPU MSCP node 2320 and an MSCP
de~ice pointer field 2334 which identifie~ the corresponding CPU node in device tree 2300. The parent pointer 2336 in ~I source CPU MSCP 2330 identifies the ~ervar CPU MSCP node ~l 2320, and child pointer 2338 identifies a linked list 1 containing disk MSCP node 2380 as a served disk for the ,¦ corresponding ~ource CPU.
,I The disk MSCP node 2380 is the node pointed to by the served disk NSC~ link 2370 from ~he device tree 2300 and Il contain~ an MSCP ~erver pointer 23~2 which identifie~ the ¦I server CPU MSCP node 2320, and an MSCP device pointer 2385 which identifies the corresponding di3k node MSCP in device tree 2300. Disk MSCP node 2380 also contains a parent pointer 2388 which identifies the source CPU MSCP node 2330.
C. Model Execut_on 1 Nith the undRrstanding of the data ~ructures presented above, a more detailed explanation can be given of how the different oparation3 are implemented using the data structures in data storage 315 and the elements of modeling interface 300 and 350 in Figure~ 3(a) and 3(b). The ¦ explanation which follow~ will usually refer ~u~ to the ~worrlec. elementY in Figure 3(a)/ but it ~hould be under~tood that for . I?;NEC~N. HENDE~50 ;.~R.~EO~'. G,~RRETT
~ DUNNER
1300 ~ 9TRrliT. N. W.
~IIINOTON. OC 2000~ 1 ~U~0~409-40oo !i _53~
Il 1,l , 2~737 ~3 1 the mo~t part the elements in Figure 3(b) will perform equivalently.
Eigure 24 includes a generalized flow diagram 2400 Il explaining how the modeling in~erface of this invention I reacts to inputs received from operators using modeling interface main menu 500 shown in Figure 5(a). The software ! for managing the display, the windows, and the cursor are well-known to persons skilled in the art. Preferably that Il software would be resident in display logic 322 and keyboard ll logic 323, although such software, or alternative means of i control such as microcode, PLA~, etc., could be implemented I¦ in a number of equivalen~ manners con~iisT:ent with the present il invention.
j' When main menu 500 i8 displayed, keyboard logic 323 wait~i for an operator input to designate the Relection of an ¦ option. When that input is received (Step 2410), a ¦I determination i~ made of tha type of input. If the FIhE
¦¦ option wa~i selected, then a FILE procedure is executed (Step Il 2420). If the S~T option is selected, a SET procedure is 11 executed (Step 2430). If the ADD option is selected, an ADD
¦ procedure i~ executed (Step 2440). If the DUPLICAT~ option i3 ~el~cted, a DUPLICA~E procedura (Stap 2450) i~i exscuted.
If the MOV~ option i8 selected, a MOVE procedurs i~i executed (Step 2460). If the REMOVE option i~i selected, a RE~OVE
¦¦ proceduro (step 2470) i~ executed. If the VIEW option i~
~worrlc~ !i selected, a VIEW procedure is executed (S~ep 2480). If the rlNNECA~I. HENDER50N ¦l FARABOW, CARRETT ~¦
DUNNER ¦ j 300 ~ 9T~ T, N. W. j NOTON. DC 20005 1 1 l Z02 ~0a-4000 '~
, I
i l SOLVE option is selected, ~ SOLVE procedure is executed (step 2490).
At the conclu~ion of procedures 24~0-2490, the di3play Il of display/keyboard 320 is updated as nece~sary (Step 2495).
S ~I For example, if the execution of one of the procedure~ caused I the display da~a to become stale, that data will then be displayed in bold text. After the display is updated, '1 control is returned to main menu 500 and Step 2410 to await .l another input.
1, 1. ~3 i; Figure 25 shows a flow diagram 2500 for implementing th~
FILE procedure 2420 in Figure 24. In the preferred ¦ implementation, the specific functions performed during the ~¦ FILE option are preferably implemented by parser3 310 and 34 i; in Figure 3(a), or by par~er~ 360 and 390 in Figure 3(b), although it i~ not crLtical to the pre~ent invsntion to have the parsers implementing these functions. These functions ~i could, for example, be implemented by other element~ by . I central software control.
¦ In flow diagram 2500, the operator i~ queried for an ¦ indication o~ the suboption de~ired. Upon receipt of an ¦ input from the keyboard specifying a type of input (Step ¦ 2510), a determination is made of the ~ype of input. If the j input indicates selection of the LOAD ~uboption, the operator I is queried for the name of the model file. When modeling ~AwOrrlccg !i interfacs 300 receive~ that name (Step 2515), ths model file FI~NECAN HENDER50N, ~DE;NNER l with the sp~cified fil~ name i8 loaded from th~ .MDL file 305 1300 I STREI!T, 1~. W.
W~9HINOTO~. DC 20009 ,20240~000 -55-2~ll7~3 ~ ' 1 1 into the modeling interface 300. Upon conclusion of the loading, ~he modeling session is continued.
If either the WRITE or EXIT suboptions were selected by I the operator, the current model is written to .MDL file 345 (step 2530). In the case of the ~RITE option, the modeling ;, session is continued (Step 2540). In the casa of the EXIT
option, the modeling session i~ ended (Step 2550).
¦ If the QUIT suboption is chosen by the operator, the I operator is then a~ked whether the current model file should I be written to disk (Step 2545). If the operator responds in the affirmative, the current model file is written to .MDL
Ij file 345 (Step 2530), and the modeling session is ended (Step il 2550). If the operator responds in the negative, the model I¦ se~sion i8 ended without writing the model file to .MDL file ~ 345 (Step 2550).
! 2. SET option Figures 26(a) and 26(b) show a flowchart 2600 containing ¦ the preferred implementation for executing the SET procedure , (Step 2430 in Figure 24). In the preferred implementation, 1 many of the functions perA~ormed in executing the SET
procedure are performed by di~play logic 32? ad~usting data in display context portion 318 (Figure 3(a)). Changer 330, on the other hand, perform~ the functions which involve either calculations or the ad~u~tment of ~he specific data 1 ~tructures in ~tructure context 317. The division of ~AW OrrlC~ I' re~ponsibilities among ~he different elements of modeling -INNEC~N. I!E~iDERS0N ' F.'~R~30W. G~RRETT
~!1 Li 1;~:~; E R
1300 ~ 9Ta~:~T, Y. W.
W~plNOTOY. OC 2000~;
~1~202-40_-4000 l -56-!l .1 1 7 ~
l ~¦ interface 300 and 350, however, are not critical to th~
¦¦ invention and could be accomplished in equivalent manners.
¦ In flow diagram 2600, when an operator has selected the ,I SET option, a menu is presented asking for a selection of a I suboption. In response, the opera~or supplies an input.
When that input is received, one of several actions will 'I occur.
i~ If the operator has selected the DISPhAY MODE suboption Il (Step 2610), then display/keyboard 320 presents the operator ~i with a menu asking for an indication of the display mode ¦ desired. When the desired display mode information i~
Il received from the operator (Step 2610), that information ls stored by keyboard logic 323 (Figure 3(a)) into display ¦ context data 318. Display logic 322 then uses the stored 1I information to con~rol the di~play of the information on ¦¦ display/k~yboard 320.
If the operator ha~ in4tead ~elected the CURRENT
WORKLOAD suboption (step 2610), the operator is ~ueried via a , menu whether to ~t the WORRLOAD or ~et the SOURCE CPU (Step ¦ 2620). If the op~rator wlshes to set the WORRLOAD, tha oparator i~ pr~s~nted with a menl~ to determine the idontification of the workload. Once the modeling interface 300 receives the workload identifica~ion (step 2622), that information is ~torsd by keyboArd logic 323 into the display context area 318 (Step 2625).
LAw~rr,cc, I~ the operator instead wishas to ~et the SOURCE CPU, FIN#ECAN HENDER50:~;
FARABOW. CARRETT
8 D1~NNER I the operator is requested, via a menu, to ~upply an 1300 1 5TREET, N. W.
WAg~llNOTON. DC Z000 I 20Z.-01~-~000 Il -57 ,1 ~ 0~ ~ 3"~ ~' l I identification of the SOURC~ CPU- When the modeling interface 300 receives that identification (Step 2627), l~ keyboard logic 322 stores that identification into display context portion 318 (Step 2628).
If, after selecting the SET option, the opera~or requested the BALANCE MODE suboption (Step 2610), the 1 operator is asked, via a menu, to indicate whe~her the operator wishes to balance the model or specify a balance ' mode (Step 2630). If the ~perator requests to balance the ll model, for example to ensure that all the branching l,, probabili~ies for each workload add to 100% (which may be il necessary depending upon the .MDL file received or becau~e of Il other changes made to the probability distributions), the ¦1 model i~ balanced IStep 2635), preferably by changer 330.
1l If operator in~tead wi~he~ to specify a balance mode, Ij the operator is asked to supply that balance mode, again i. using a menu in the preferred implementation. When modeling ¦l interface 300 receives the ~pecified balance mode (Step ! 2632), which can be either uniform or relative, keyboard il logic 323 ~tore~ that mode into display context portion 318.
I~, after selecting the SET option, the operator chooses the PROBABI~ITY DISTRlBUTION suboption (Step 2610), then the operator i3 queried~ via a menu as to the type of device for l which the probability distribution i~ being set (Step 2640 in 111 Figure 26(b)). The device type can either be a user group, a ~wor~lc~ CPU or a disk FI~EGANI, HE~DERSO~
FARABOW. GARRETT .
~S Dl~ IER .
1300 1 3TREET, N. W. .
WAS~IINOTON. DC 20003 j 3Ozoz 4o~ ooo ~ 58-20~J i-' 1 ¦ Next, the operator is presented a selection menu ! appropriate to the selected device type to identify a device ¦ and a workload for which the probability is to be set. When l¦ the operator selects the desired identification, the modeling ' interface receives the selection (Step 2642).
'¦ Next, the operator is pre~ented with a display screen il for input of the probabili~y distribution and other nece~sary ¦ data. The user supplies the probability distribution and ,I data, which can include information such as whether the ll probability distribution is FIXED or FLOATING. Once that I¦ information is received by modeling interface 300 (Step ¦¦ 2645), the probability distribution and data are stored by ¦¦ changer 330 in the node of workload trea 640 corresponding to ¦¦ the identified device (step 2648).
ll If the operator input in response to the main menu 500 !¦ was a request to set a WORRLOAD P~RAMETER (Step 2610), then iI the operator is presented a menu asking for a workload identification. When that identification i~ received (Step 2650), the operator iY presented a menu to supply an identification of ths workload parameters. When modeling interface 300 receives that identification, as well as the value~, from the operator (step 2655), changer 300 stores those workload parameters into the appropriate workload node in stru~ture context portion 317 (Step 2658).
If the operator reque~ts the SYSTEM LOAD option after ~worrlcc~ selecting the SE~ option from main msnu 500 (Step 2610), the Fl~:~ EC~;. HE~IDERSON
r~R~DW,~ERRRETT operator i~ presented a menu a~king for an identification of 1300 1 9rREEr. N. W.
W~g~lN irON. DC 2000 _59_ Il .
~ 7 j3ij ~
1 ¦ the load type (expressed in TPS) and percen~ag2 change (Step 2660). Whether the percentage change is positive or negative ¦ also indicates whether the change is an increase or a , decrease in the load.
,j The operator is then presented with a menu indicating whether the change i~ for a single workload, a user group, or ! for all of the workload~. If the oparator indicates that the i change should be for a single workload then the operator is ~I presented with a menu asking for an identification of the 1 desired workload. When that identification i~ received (Step 2662), changer 330 increase~ or decrease~ the identified workload by the indicated percentage (Step 2665).
~Ij If the opera~or in~toad indicate3 that the load type to il be changed i8 for all of the workload~ in a user group, then i the operator is pre~ented with a menu asXing for an ; identification of a user group. Once that identification is i received (Step 2663), changer 330 acce~e3 all of the workloads to which ~he indicated user group contributes, and !! ad~uits the workloadi3 by the indica~ed percentage 'I proportionate to the identified usar group~i3 contribution to the workload (Step 2666).
the operator in~tead indicates a desire to change all of th~ workloads, ~hen the TPS for all of the workloads are changed by ~he indica~ed percenta~e IStep 2667~. This i~
1, preferably al90 accompli~hed by changer 330.
~AW O~IC~ i Returning to Fi~ure 26(a), if the operator select~ the FINNECAN. HENDER50N 1 FARA~ D~NER I SET Ob~ect Nam~ iuboption, the oper~tor i3 presented with a 1300 I ST~ 7, N. W. i, WAglllN070N. DC 20005 j.
-0~000 ~ 60-li l l ~ 7 3i~s 1 series of menus asking for an identification of the ob~ect.
When the operator selects the identification of the ob~ect ! from the menu, and that selection is received (step 2670), Il the operator is pre~ented a window asking for the name of the ¦ device. ~hen the object name is received (Step 2675~, ;I changer 330 stores that name into the name field (see field ,l 810 of Figure 8) of the node associated with the indicated ;I device tStep 2678).
,1 If the operator has selected the SET Ob~ect Type option i¦ from main menu 500 (Step 2610), the operator is presented i with the series of menus explained previou~zly regarding the I SET Ob~ect Name option to identify the ob~ect. When the !~ identification of the ob~ect i~ received (step 2680), the ¦¦ operator i8 pre~ented with a menu a~king the operator to lli identify the ob~ect type desired. Once this identification is received by the modeling interface (Step 2685), changer 330 stores that ob~ect type in the element type field (see field ii 850 in Figure 8) for the identified ob~ect (Step 2688).
I At the end of the steps in S~T option flowchart 2600, ! control is returned to main menu 500 in Figure 5(a).
3. ADD oPtion If in~tead of the SET option, the operator had cho~en the ADD option from the main menu 500, then ADD procedure 2440 (Figure 24) would be executed. A preferred jl implementation of ADD procedure 2440 i3 shown by flow diagram ~w o rlc~ 1! 2700 in Figuro 27.
E~AN. HENDERSO~: !
F.~L~aOW. G~RRETT ~1 ~I DIJNNER
1300 1 3TQ~ , N W, ~III~IOTON. OC 2000 U ` Z02 - 0~- 4000 Il -61-i' I, ~ O l~
It should be noted, that for the ADD procedure 2440, as I¦ well as for DUPLICATE procedure 2450, MOVE procedure 2460, .¦ and REMOVE procedurP 2470, the changes ~o da~a structure 315, particularly structure con~ext 317, are preferably accomplished by changer 330. In other implementations, however, other elements can be u~ed to effect the changes to the data structure 315.
In flow diagram 2700, the operator i8 first presented ~ with a series of menus for the operator to identify the type 'l of ob~ec~ to be added (Step 2710). Once that identification is received (Step 2710), the operator is presented with a ~j menu to ~upply ~he noda parameter3 for the identified ob~ect.
¦I When tho~e node parameters are recelved (Step 2720), the ,¦ operator is presented with menu~ to specify the destination ¦ of the ob~ect to bs added. For exampla, if the ob~ect to be added i5 a disk, the operator will be asked to specify whether the di k i~ to be added to an HSC channel or to a ll CPU, and then iden~ify the specific HSC channel or CPU. If l! the ob~ect to ba added i8 an HSC or a CPU, the operator will ! be asked to identi y a bus adaptor which will indicate the I bus to which the device i~ added. In tha preferred implementation, an HSC or CPU will be added to the current bus, and must be moYed using the MOVE option if thi~ is not the desired destination.
l Once the location i~ recei~ed (Step 2730), the changer ~worrlcc~ il cr~ate~ a node with the parameters and adds it to the tree in FINNEGAN HENDERSO~ 11 FARA~DUNN~ERRRETT ¦¦ ~trUCtUre contsxt portion 317 a~ the appropriato location 1300 ~ S7REET, N. w.
W~9~11NOTON. DC 2000~ ¦1 I 202 ~0 S- 000 1 --62--Il ~ J~
1 ll (Step 2740). Note that the addition of an ob~ect will likely affect the displayed data which will become stale.
Control is then returned to main menu 500.
I 4. DUPLICATE oPtion , If the operator had chosen the DUPLICATE option from main menu 500, DUPLICATE proceduxe 2450 (Figure 24) would be executed. A preferred implementation of ~he DUPLICATE
I procedure i~ chown by flowchart 2800 in Figure 28. In i flowchart 2800, the first step is to identify the node to be I duplicated, which is done in the manner de~cribed above.
Once the node identification i8 received by modeling int0rface 300 (Step 2810), the identified device is duplicatsd by copying th~ node for the indicated device ¦ exactly, and then adjusting certain of the linked list-~ to Il add the device in the model next to the davice copied (Step I¦ 2820). In the preferred embodiment, however, the MSCP and ¦¦ workload information is no~ copied for new devices. Control iR then returned to the main menu 500.
l 5. MOVE option If the operator choo~es the MOVE option from main menu 500, ~OVE procedure 2460 (Figure 24) i8 executed. The preferred implementatLon of MOVE procedure 2460 is shown by flow diagram 2900 in Figure 29.
At the out~et of flow diagram 2900, the operator ic prompted by a menu ~o indicate whether the ob~ect to be moved ~worrlc~ I i~ a workload or a device. When the operator make3 that FINNECA~. HEN5ERSON ¦
1~ DUNNER j 1300 1 3T~EET, N. W
a~l~INGTON. OC 2000~S
JV, zoz 40e-4000 i -63 .1 ~¦ 2 ~3 ~
1 ~ indication, it is received by modelin~ interface 300 (Step 2910).
I~ the operator indicates that a device is to be moved, l¦ then a series of menus are presented for the operator to 1 identify the device. When that identification i5 received by modeling interface 300 (Step 2915), the operator is prompted by another series of menu~ to identify the destination of the 1 identified device.
¦ Once the destination is received by modeling interface ll 300 (Step 2920)l changer 330 removes the node for the i identified device from its curran~ location and inserts it into the device tree structure 700 at a po~ition i! corre~pondinq to the de~tination (Step 29~5). Thi~ procedure ¦¦ involves, among other funstions, reconnection of the parent l¦ linked lists in structure context portion 317 to indicate j movement of the corre3ponding node. The data structure~ for Il the model node are alqo updatad to reflect the movement of ¦ the node.
Il Once ~tructure context portion 317 i updated by changer 330, control i~ rsturned to main menu 500.
If, after 3electing the ~OVE optlon, the operator had instead chosen to move a workload, the opera~or i5 pre ented with ~ ~eries of menu~ to identify the workload and indicate whether the identified workload i~ to be moved from a CPU or i di~k. When thi~ inform~tion i~ recaived by modeling so~ interface 300 (Step 2930), modeling interface 300 next ;.~R.~90W. G~RRETT
g Dl!~J~;ER
~00 1 iT17CCT, N. W
~II~OTOt~. DC ~0005 ~
202 400'1000 11 ~I -64-l 2 '~3 ll 7 ~3~ ' de~ermines whether the node type i~ a CPU or a di~k (Step ! 2935 ) .
If the node type is a CPU, then the operator is presented with menus to identify source CPUs of the workload, the destina~ion CPUs of ~he workload, and the percentage of the workload to be moved. When this information ~s received :. (step 2940~, the CPV load i~ redistributed by moving the indica~ed percentage of the identified workload to the . de3tination workload (i.e., those which are already supporting that workload and whose probabilities are not .l already fixed) according to the balancing mode ~S~ep 2950).
¦ An example of how this might be done i8 shown in Figure 30. In Figure 30, 50% of workloadl is to be moved from CPU1 ¦ to CPU2 and CPU3. Bsfore ~he move, the branching pxobability for CPU1 is 25~, the br~nching probability for CPU2 i~ 35~, I and the branching probability for CPU3 i~ 40%.
After the move, 50~ of workloadl will have been taken from CPU1, ~o the remaining branching probability for CPU1 would be 12.5~. If a uniform balancing mode was cho~en, then the amount of the workload taken away from CPU1, or 12.5~, . would be ~h~red among CPU2 and CPU3. Thu~, both CPU2 and CPU3 would gat 6.25~, resulting in a branching probability for workloadl of 41.25% for CPU2 of 46.25~ for CPU3. This i~
repxe~ented by the leftmost number in the parenthesis in the 'I AFTER column in Figure 30.
,~E~A~HE~DER50N,I If a relative balancing mode is cho3en, then the ratio FARABOW, GARRETT I i ~Du~ER .1 of the balanclng probability for CPU2 and CPU3 must fir~t be 1300 1 5T`~EET. N. W. :
~VASNINOTON. DC 20005 , i 65-I 1l .
Ll 7 determined. One way of accomplishing thi5 i9 to add the branching probabilities of the affected CPUs for the identified workload and then determine the ra~io of each affected CPU to the sum. The ratio will not only be the percentage of the branching probabilities of CPU2 and CPU3 before moving the workload, it is also used to determine the amount of the moved workload which each CPU should receive to maintain the samo ratios.
Using this calculus, CPU2 has a ratio of 35/75 or about 47~, and CPU3 has a ratio of 40/7S or about 53~. Thus, 47~
of the change in CPUl's branching probability for workloadl, or 47~ of 12.5~, would be add~d to CPU2~s branching probability for workloadl and 53% of 12.5% would be added to CPU3's branching probability for workloadl. The re~ult would be that CPU2 would have 40.83% as its new branching probability and CPU3 would have 46.67 a~ its new branching probability. These are shown by the rightmost value~ in the parenthesis in the AFTER column for CPU2 and CPU3 in Figure 30.
Preferably, this calculation would be done by changer 330 in Figures 3(a) and 3(b), although it i~ not important to the pras2nt invention which element i9 performing tha calculation~.
After the workload~ are redistributed by percentage, modeling interface 300 determines whether any o~ the destination CPU~ are new participantq in thi~ workload (step . I~NEC\N, HENDER50N
~AR~80W, G~RRETT
:~ D~:NNER
1300 ~ 3TRU T, '1. W.
WA'.IIINOTO~.l. OC ZOOO~
1 202 ~0~ 000 -~6-3 ll 7 .~ ~ ~
¦ 2955). If not, or after the creation of the disk branching ¦ probabilities, control is returned to main menu 500.
If ~o, then a new CPU branching probability node has to be created to reflect the newly computed branching probabilities (Step 2960). The new branching probability node must be set with a value that reflects the redistributed percentage. For example, a~sume that prior to moving a workload, the following condition existed:
Svstem Load Diskl Disk2 CPU1 20% 80~ 20~
CPU2 80% 10% 90%
CPU3 0~ o%
If 50~ of the workload is moved from CPU1 and CPU2 onto CPU3 t the result would be: -Svstem Load Di~kl Disk2 CPU1 10% 80% 20 CPU2 40~ 10~ 90%
. CPU3 50~ 24% 76%
.' The load for di~kl is obtained by taking the percent of the j load on diskl from CPU1, or 20% x 80~, and adding it to the ¦ percentage of the workload on diskl form CPU2, or 80% x 10~.
'¦ The re~ulting 8um iS 24%. Similarly, if the load for disk~q ! from CPUl~ or 20~ x 20~ is added ~o the percen~. of the worXload in disk2 on CPU2, or 80% x 90%, the sum i 76%, which i a percentage of the workload shown in CPU3 for ~AW orrlc ~ l, q ::NNEC~N HENDERSON
F~R.~90W. CARRETT
1~00 1 5TR'Er~ N. W.
~WOT0R. DC Z0005 I`Z02 ~01~-4000 , , ~, ,~1 5~ a ~1 7 j ' ¦ If the workload to be moved is from a disk, then the ¦ operator is presented a series of menus asking for an identification of the source CPU nodes for the disks. When this identificaTion is received (Step 2970), the operator is then asked, via other menus, to identify the source disks of ; the workload, the destination disks of the workload, and the percentage of the workload to be moved. When this identification is received (Step 2975), the workload~ are redis~ributed by percentage (Step 2980). Preferably, this involves reducing the percentage of the load from all of the source nodes, and increasing the percentage of the load to all of the deitination nodes according ~o the balancing mode . in the same manner as is done when a CPV load is moved.
After redistribution of the workloads, control is returned to main menu 500.
6. RENOVE o~tiQn If operator had selected to REMOVE option from main menu 500, then RE~OVE procedure 2470 (Figure 24) i9 executed. A
preferred implementation of REMOVE procedure 24~0 is shown by flow diagram 3100 in Figures 31(a), 31(b) and 31(c).
. In flow diagram 3100, the operator is first presented I with a menu to determina the type of ob~ect to be removed l ( St8p 3110). If the operator respondis by identifying a I device, ~he operator is preiented with a menu as~ing for an :l identification of the specific device to be removed, and tha~
~W O~IC~9 ~ identification is received by the mo~eling interface ~Step -INNECAN. HENDER50N
FARA30W. GARRETT
j3 DUNNE~ I 3112 ) .
1300 ~ gl'Q~T, N. ~q, !
WA~I~IN31'C1N, OC Z000~ !
I Z02'-09-4000 , -68-.1 2 ~
~j If the operator identifie~ a CPU, then changer 330 first deletes ~he child nodes o~ that CPU (Step 3114). The deletion of the child nodes, such as disks, is di~cussed below .
Next, changer 330 deletes the ~SCP source CPU node~
(Step 3116). The source CPU nodes can be located using the MSCP linked list for the corresponding node. Deletion of the source node~ also daletes the served disk nodes that were its children, requiring further modification of device tree 700 and MSCP tree 660 as appropriate.
Next, the corre~ponding sen~er node MSCP sllbtree for that node i~ deleted if one is pre~ent ( Step 3117 ) . The tree can be found using the MSCP pointer 1310 (Figure 13 ~ of the device node. Thi~ deletion will alRo have ramifications on all the device nodes corresponding to source CPU nodes or served disk nodes for the delsted MSCP tree, and must be handled appropriately.
After deletion of the MSCP server nodes, the CPU branch probabilities for each workload supported by the identif ied CPU must be rebalanced f or the remaining CPUs ir~ accordance with the balance mode (step 3118). The details fer such , rebalancing was de~cribed above in the explanation of the MOVE: f low diagram 2 9 0 0 .
Next, the nodes for each of the adapters for the CPU are i deleted (Step 3119). Thi~ effectively disconnects the AwO,rc~, deleted CPU nodes from the bu~es.
F.'~R.~30W. G~RRETT
1~00 I ST1111~T. N. W.
~1NOTON~ OC 20Q0 1 20i~ 40~ 000 5~ ; fjl 'c~
The final step in removing a CPU node i~ the deletion of the stati~tics list and the deletion of the node itself (Step 3120). After that, control is returned to main menu 500.
If the type of node to be removed is a disk, or if a disk is to be deleted as part of the removal of a CPU, the MSCP served disk nodes are deleted (Step 3130). Such nodes can be located by the MSCP linked li~ts for the node corresponding to the disk to be deleted. The deletion of a disk node from the MSCP tree involves the ad~ustment of the MSCP ~ubtree~ as well to eliminate any pointer~ to the deleted disk.
AftPr deletion of the MSCP di~X nodes, the disk branc'n probability nodes for the iden~ified di~k are deleted by changsr 330 (Step 3132). Such probability node~ can be identified using the workload linked lists for the node corresponding to the identified dis~.
Noxt, the disk branch probabilities for each workload , that was supported by the identified disk are rebalanced j (Step 3135). Again, this rebalancing i8 performed ~eparately 'j for each workload~ and i8 done in accordance with the '. identified balancing mode.
The final ~tep in the removal of a disk is the deletion of the ~tatistic~ li3t, if present, and the deletion of the I di~k node it~elf (Step 3120). When this i8 done, control is Awo~rlcc~ I returned to the main menu 500.
I~NECAN HENDERSON
FARA30W. GARRE~T
~ DUNNER ~ !
1300 I Srl~l~ET, N. W, WA9NIli0TON. DC 2000!1 I 20Z - ~0 9 - ~00 0 2 ~ ll I r,j ~ -,¦ If the device to be removed has been identified by the operator as something other than a disk or CPU, such as an HSC, changer 330 first deletes any child nodes whose only parents are either the ob~ect to be deleted or a child of an object to be deleted that doeR not have a parent which survive~ the deletion (Step 3140). For example, if an NI bus were deleted, CPUs that still were connected to a CI bus ; would not be deleted, nor would the di~k~ connected to that CI bus. All CPUs connected only to the NI bu~, however, would be deleted, a~ would any devices connected only to those CPU4. The deletion of CPUs and disks ha~ been described above.
For the child nodes that have more than one parent, their parent linked li~ts ar~ ad~usted to reflect the absence of the parent which is being dele~ed (Step 3142).
Finally, the node for the device to be deleted is itself deleted (Step 3120). If the node has a statistics list, it is deleted. Control i3 ~hen returned to the main menu.
If the operator i~ using ~he REMOVE option to delete an ! MSCP elemant, the ~tep~ shown in Figure 31(b) are executed, preferably by changer 330. The first datermination made i~
what the tyye of device i~ to be deleted from the ~SCP
,¦ element (S~ep 3150). Thi3 iY preferably done using a menu.
If an MSCP servsr CPU node i~ to be dele~ed, the node in the MSCP tree for the qerver CPU to be deleted is acces~ed by changer 330 (St~p 3151). Thi~ is preferable done through the -INNEGAN. HENDER90N
FARA90W. GARRETT
~D~NNER MSCP pointer 1310 (Fi~ur~ 13) of the d~vice nod~.
1300 ~ 9Ti~EET, N. W.
WAS/lWOTO~ . DC 20003 1 202 ~01!1 ~000 ~ ~) Ll r~
Once the MSCP node is accessed, the source nodes in the trees are decoupled from the CPU device node (Step 3152).
This i3 accomplished by changer 330 in the preferred implementation by adjusting the MSCP linked lists for the CPU
nodes. The source CPU MSCP nodes for the ~SCP tree are then deleted (step 3153).
Next, the disk device nodes in the MSCP tree are decoupled from the nodes in device tree 700 (Step 3155). The device tree nodes can ba located u3ing the disk MSCP
pointers, such as pointer 2382 in Figure 23. Decoupling involves adjustment of the MSCP linked lists of the nodes in device tree 700 for the corre~ponding disks. After decoupling, the disk CPU ~SCP node~ are deleted (step 3157).
Finally, the server CPU NSCP node is deleted (Step 3158). Such deletion is accompanied by the clearing of the MSCP pointer 1310 (Figure 13) in the corre3ponding device tree node. Control i~ then returned ~o main menu 500.
If one or more source nodes are to be removed, the ~ corresponding server CPU node is acces~ed tStep 3160), and I from that access, the designated source CPU nodes are acces~ed (step 3162).
Next, the sourca CPU nodes are decoupled from the i corresponding C~U device node by corrsc~ing the linXed list~
accordingly (Step 31b5). Then the source CPU NSCP nodes are I deleted from the MSCP trees for tho corresponding ~erver node .AwOrr.ce~ (Step 3168). Control i~ then returned to main menu 500.
!~;EC~. HE~DER50~ ¦
F.~R.~30W GARRETT
~ DU~;~ER ~;
~:100 I S~T~T, . ~'1. !
5111N /SON. I~C 2000 I `202'400'.-000 2~1~7~7; :.~
If a disk is to be removed from an MSCP relationship, changer 330 accesses the corresponding server CPU MSCP nodes (Step 3170), source CPU MSCP nodes (step 3172), and disk MSCP
nodes (Step 3175). This access is preferably done by locating the proper MSCP trees.
After the disks are acce~3ed, the corresponding di~k device nodes in device tree 700 are decoupled from the NSCP
tree (Step 3178), and the disk MSCP nodes are deleted (step 3179). When this is finished, control is returned to main menu 500.
; Returning to Figure 31(a), the operator could also choose to delete a user group. If ~o, the preferred implementation step for such a choice are shown in Figure 31(c).
The operator i8 fir~t presQnted with a window asking for . an identification of the u~er group to be removed. When the operator makes tha choice, changer 330 identifies the corresponding user group nodes (Step 3180).
Once the user group node i~ identified, changer 330 j deletes the workload branch probability nodes for that u~er group (St~p 3182). Tho workload pointer~, such as pointer . 1774 in Figure 17, can be u~ed to find the needed user group branch probability node After deleting the branch probability node~, changer 330 . rebalanceg the other user group~ branch probability nodes F NNE~N HENDERSON according to th~ balancing mode (Step 3185). If a user group FAR~BOW, CARRETT
h Dl,~JNER
1300 I STR~CT, IJ. W.
WA9~ 0T0-~. DC Z000 I 202 ~011 ~000 7 ~
wa5 respone~ible for 100% of any workload, that workload is also delated.
Once this is done, the node for the user group i~
i deleted (Step 3199). Control is then returned to main menu 500.
If the operator chooses to remove a workload, then the i operator is presented with menus to select the workload to be ! removed. Once the workload i~ identified, changer 330 finds the workload node associated with that workload (step 3190).
Next, changer 330 delete~ all disk branch probability ~ nodes for that workload (Step 3132). This i~ ea~ily ¦ accomplished using the tree structure for the workload tree.
'I Next, changer 330 deletes the workload CPU branch I probability nodes (Step 3195). Thi3 too i8 accomplished ¦ easily by virtue of the workload tree's structure.
Next~ the user group branch probability nodes for the identified workload are deleted (Step 3~97). Thi3 too makes use of the structure of the workload tree in the preferred implementation.
i ~inally, the statistic block~ for this workload in each I devico'~ qtatistic~ list are deleted (step 3198).
When all these tasks have been completed, ~he node for ! the corresponding workload i~ deleted (Step 3199). Con~rol . i8 then returned to the main menu 500.
7. VIEW_o~tion If, in flow diagram 2400, the operator had chosen the ;EC~;. HE~;DERSO~;
F.~R.~BO~ GARRETT
3 D~ER VIEW option, then VI~N procedure 2480 would be implemented.
~300 1 ST ;~r, N. ~.
~9~1NOTON. DC 2000~ ¦
, ~02 -03-4000 :I
''I
!
S~il 7~, `
¦ Figure 32 contain~ flow diagram 3200 showing a preferred implementation of view procedure 2480.
In flow diagram 3200, the operator is presented with a I menu a~2king for an identificatian of the device type. When the operator makes a selection and it is received by modeling interface 300 (Step 3210), the operator is presented with a series of menu~ to identify a ~pecific device. When modeling interface 300 receives the operator~s identification of a device (Step 3220), display logic 322 creates the desired zoomed view (Step 3230). This involves the application of display techniques which would be known to persons skilled in the art, and thus does not need to be de~cribed further.
After creating the desired view, the control i~ returned to main menu 500.
8. SOLVE o~tion The rsmaining option which an operator could select from the main menu 500 i3 the SOLVE option. If that option is chosen, then SOLVE procedure 2490 is executed. Preferably, procedure 2490 i~ executed by solver 335 in Figures 3(a) and 3(b).
The preferred implementation of solver 335 is described in detail in U-S.S-N. 07/280,171 to Kwaq et ak , which i~
herein incorporated by reference. Kwaa et al. de cribes a device for taking information de~cribing a computer ~y~tem, generating a mathematical model of the computer system, and .AwOrrl~c. ; evaluating result~ u3ing ~he computer 3ystem ststi~tic~.
INNE(;AN~ HENDRSON
F.~R.~30W. G~RRE~
5 D~NNER
1300 1 57R~I~, N~ W.
WA~lllNOrON~ DC Z000~1 ` 202 oa - Aooo ~3Ll7~, ~
In the preferred implementation of the invention, solver ¦ 335 retrieves the data from data storage 315 (Step 3310).
Preferably, solver 335 would have code for retrieving the configuration data directly from the tree structures in data storage 315. Retrieval of data from trees is well known to persons of ordinary skill in this art.
If, however, solver 335 is designed to retrieve data in an array format, then a parser, such a~ parser 390 shown in Figure 3(b), can be used to convert the data from a tree structure into an array structure for use by solver 335.
I Once the data is retrieved, ~ol~er 335 determines new i metrics ba~ed upon a mathematical model of the computer system configuration (Step 33~0). The metrics include information such as queue length~ and delays in the system.
When solver 335 complete~ it~ calculations, it writes those new metrics into the da~a structure 315 (Step 3330).
Again, in the preferred embodiment, the metrics would be written directly back into the device, workload, and user group tree ~tructures. Solver 335 could also place the metric~ data into an array structure. In this case, parser 390, as well as par~er 365, both shown in Figure 3(b), could be u~od to place the new metrics values into the appropriate tree ~tructure~.
When ~olver 335 comple~e~ it~ calculations and storage ¦ of data, control i~ returned to main menu 500.
.~wOFrcc, l D Parser INNECAN HENDERSON
FARA30\1V. CARRETT
~I Dl,'NNER
1300 I STF~En~ . W. I
W~5~1~'10T0~. C)C Z0005 I Z02 ~0 1-. 000 i t~ r Y J ~7 ,1 il The only elements of modeling interfaces 300 and 350 ¦ that hsve not been discussed in greater detail are the parser~, such as parsers 310, 340, 360, and 390, and interface 365. Parser construction is generally known to persons skilled in the ar~, especially when providing an interface to tree structures and linked lists.
Figure 34 shows thc format 3400 for the .MDL files 305 ; and 345. Parsers 310, 340, 360 and 390 wo~ld then be designed to provide an interface for such format~, or for any other format used in an implementation of the invention.
E. Summarv From th2 preceding explanation it can be seen how the modeling interface of thi~ invention achieves the desire~ set forth. This invention prov.ides a mechanism for performance analysis and capacity planning that allows for a more meaningful presentation of performance information. It does I so using the displays and menu~ de~cribed above.
! The present invention also provides an improved I mechanism for changing the configurations of the computer i system, at least in a virtual ense, to detenmine the effects of ~uch changea. That improved mechani~m includes the di~play of the computer system configuration as well as the di~play of the selected metrics with that configuration.
Similarly, the precent invention provida~ an improved mechanism for pre enting the effect~ of the changes in FI~E~HrE~'D'ER50~i configuration in a manner which allows ready deci~ion making.
F.~RA30W. G~RRETT
.~Du~ER The display discussed above provides a meaningf~Al 1300 ~ STqEET. N. W.
1 20~ 409--000 1 r~ r j ~
presentation of changes to a computer system being modeled to enhance capacity planning and p~rformance analysis.
I The foregoing description of preferred implementations I of the invention has been presented for purposes of illustration and description. It i~ not intended to b~
exhaustive or to limit the invention to the precise forms disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from practice of the invention. The embodiments were chosen and described to explain the principles of ~he invention and its practical application to enable one skilled in the art to use ~he invention in variou embodiments and with various modifications as are ~uited to tho particular u~e contemplated. It i~ intsnded that th~ scope o~ the invention be defined by the appended claims and their equivslents.
i i .
L~W orrlc~
:I~;NEC~;, HE~DERSO~: ¦
F~R~30~. CARRET~ ;
~S) DllN~:ER
11100 I STi~T, N. W.
W~g~NOTON. DC ZOOO~
,202.0~000 1 ~78-.1
Claims (47)
1. A method of evaluating the performance of a computer system which is described by a configuration representing physical devices, the connections of the physical devices in the computer system, and workloads which are processes that use system resources provided by the physical devices, the method comprising the steps, executed by a modeling data processor, of:
creating a model of the configuration of the computer system in the data processor;
displaying, on a visual display device coupled to the modeling data processor, a diagram of the configuration of the computer system;
receiving an input to modify the configuration of the computer system;
modifying the model of the computer system in response to the received input to reflect the modified configuration of the computer system;
determining new values of selected metrics for the modified model of the computer system, metrics including measurable values representative of the performance of the computer system; and displaying on the visual display device a diagram of the modified configuration of the computer system.
creating a model of the configuration of the computer system in the data processor;
displaying, on a visual display device coupled to the modeling data processor, a diagram of the configuration of the computer system;
receiving an input to modify the configuration of the computer system;
modifying the model of the computer system in response to the received input to reflect the modified configuration of the computer system;
determining new values of selected metrics for the modified model of the computer system, metrics including measurable values representative of the performance of the computer system; and displaying on the visual display device a diagram of the modified configuration of the computer system.
2. The method of claim 1 wherein the step of displaying a diagram of the modified configuration includes the substep of displaying on the diagram the new values of the metrics.
3. The method of claim 1 further comprising the step of receiving, from the computer system, data describing the configuration of the computer system, and wherein the step of creating the model of the configuration of the computer system includes the substep of building the model of the computer system configuration from the data describing the configuration received from the computer system.
4. The method of claim 1 further including the step of receiving initial values for the selected metrics based on actual operation of the computer system.
5. The method of claim 1 wherein the step of displaying a diagram of the computer system configuration includes the substep of displaying representations of the physical devices and representations of the connections of those devices.
6. The method of claim 1 wherein each of the workloads in the computer system is associated with the ones of the physical devices which provide system resources for that workload, and wherein the step of displaying a diagram of the computer system configuration includes the substep of displaying at least one of the workloads in the computer system.
7. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input adding a new physical device to the configuration.
8. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input deleting one of the physical devices from the configuration.
9. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input changing connections of one of the physical devices in the configuration.
10. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input changing one of the physical devices in the configuration.
11. The method of claim l wherein the step of receiving an input includes the substep of receiving an input adding a new workload to the configuration.
12. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input deleting one of the workloads from the configuration.
13. The method of claim 1 wherein the step of receiving an input includes the substep of receiving an input changing one of the workloads in the configuration.
14. The method of claim 1 wherein the step of modifying the model includes the substep of determining a redistribution of the workloads among the physical devices in response to the modification to the model due to a change in one of the workloads.
15. The method of claim 14 wherein the step of determining the redistribution of the workloads includes the substeps of identifying for the one of the workloads that is changed a set of physical devices in the model which would be affected by the change in the one workload, and redistributing the one workload to the physical devices in the identified set.
16. The method of claim 15 wherein the substep of redistributing the one workload includes the substep of distributing the same percentage of the change in the one workload to the physical devices in the identified set.
17. The method of claim 15 wherein the substep of redistributing the one workload includes the substep of distributing percentages of the change in the one workload to the physical devices in the identified set proportionately to the ratios of percentages of the one workload supported by the physical devices in the identified eset before the change in the one workload.
18. The method of claim 1 wherein the step of creating the model of the computer system configuration includes the substep of representing the model of the computer system configuration in the data processor in a device data structure which is organized hierarchically to reflect the relationship of the physical devices of the computer system.
19. The method of claim 18 wherein the step of representing the model of the computer system configuration in the device data structure includes the substep of representing the model of the computer system configuration as a tree structure having nodes corresponding to the physical elements.
20. The method of claim 19 wherein the method further includes the steps of representing the workloads as entries in a workload data structure, and associating each the workloads represented in the workload data structure with the representations in the device data structure of the physical devices which supply system resources to the associated workload.
21. The method of claim 20 wherein the step of representing the workloads in the workload data structure includes the substep of including in the workload data structure information regarding the amount of the system resources required from the associated physical devices by each represented workload.
22. The method of claim 21 wherein the step of including in the workload data structure information regarding the amount of the system resources required from the associated physical devices by each represented workload includes the substeps of including in the information an indication of the total amount of system resources required by each workload, and including in the information an indication of the fraction of the total amount of system resources supplied by each of the associated physical devices.
23. The method of claim 1 wherein the users of the computer system which contribute to the workloads are organized into user groups, and wherein the method includes the steps of representing the user groups as entries in a user group data structure, and relating the each of the entries in the user group data structure to corresponding workloads.
24. The method of claim 1 wherein selected server ones of the physical devices in the computer system are capable of providing facilitated access to other source ones of the physical devices, and wherein the method further comprise the steps of representing as entries in an access data structure the selected server and source physical devices, and associating the entries in the access data structure information to the corresponding physical devices.
25. A data structure for modeling a computer system containing a plurality of physical devices supporting a plurality of workloads, the data structure residing in a modeling data processor and comprising:
a plurality of first data entries organized into an easily modifiable first data structure, each of the first data entries corresponding to a different physical device of the computer system, the first entries including device id means for identifying the corresponding physical device, and device data structure means for indicating a hierarchical relationship in the computer system configuration of the corresponding device with selected other ones of the physical devices; and a plurality of second data entries organized into an easily modifiable second data structure, each of the second entries each corresponding to one of the workloads which the devices in the computer system support by supplying system resources to the workloads, each of the second entries including workload pointer means for identifying the corresponding workload, device pointer means for associating the corresponding workload with the ones of the devices supporting the corresponding workload, and probability means for quantifying the system resources supplied to the corresponding workload by the associated one of the physical devices.
a plurality of first data entries organized into an easily modifiable first data structure, each of the first data entries corresponding to a different physical device of the computer system, the first entries including device id means for identifying the corresponding physical device, and device data structure means for indicating a hierarchical relationship in the computer system configuration of the corresponding device with selected other ones of the physical devices; and a plurality of second data entries organized into an easily modifiable second data structure, each of the second entries each corresponding to one of the workloads which the devices in the computer system support by supplying system resources to the workloads, each of the second entries including workload pointer means for identifying the corresponding workload, device pointer means for associating the corresponding workload with the ones of the devices supporting the corresponding workload, and probability means for quantifying the system resources supplied to the corresponding workload by the associated one of the physical devices.
26. The data structure of claim 25 wherein the first data entries also include library pointer means for identifying a library containing parameters for the corresponding device.
27. The data structure of claim 25 wherein the first data entries also include statistics id means containing values for metrics for the corresponding device, metrics including measurable values representative of the performance of the computer system.
28. The data structure of claim 27 wherein the statistics id means includes at least one statistics block, each of the at least one statistics blocks corresponding to a different one of the workloads supported by the corresponding device and containing values for the metrics associated with the corresponding one of the workloads.
29. The data structure of claim 25 wherein the first data entries also include workload pointer means for identifying the workloads supported by the corresponding device.
30. The data structure of claim 25 wherein the first data entries also include element type means for identifying the type of the cor-responding device.
31. The data structure of claim 25 wherein the first data entries are organized into a tree data structure, and wherein the device data structure means in each of the first data entries includes tree structure means for identifying the ones of the first data entries having a direct tree structure relationship with the corresponding first data entry.
32. The data structure of claim 25 further including a third entries each corresponding to a different workload, each of the third entries including workload id means for identifying the corresponding workload, branching id means for identifying at least one of the second entries, and workload metrics means for listing values for certain parameters for the corresponding workload.
33. The data structure of claim 32 wherein the third entries also include statistics id means containing values for metrics for the corresponding workload, metrics including measurable values representative of the performance of the computer system.
34. The data structure of claim 25 wherein the second entries also each include means for indicating a hierarchical relationship among the third entries reflective of the hierarchical relationship of the physical devices.
35. The data structure of claim 32 wherein each of the second data entries is associated with the one of the third entries which corresponds to the same workload that the second entry corresponds to, wherein the workload metrics in each of the third entries each include means for indicating an amount of the system resources of the computer system required by a corresponding workload, and wherein the probability means in each of the second entries includes branching probability means for specifying the fraction of the computer system resources which is supplied by each one of the associated physical devices for the corresponding workload.
36. The data structure of claim 25 wherein the users of the computer system which create the workloads are organized into user groups, and wherein the data structure further comprises fourth entries including user group id means for identifying a corresponding one of the user groups, and user group workload id means for indicating the associated ones of the workloads contributed to by the corresponding user group.
37. The data structure of claim 36 wherein the fourth entries include user group probability entries each corresponding to a different one of the associated workloads and containing the user group workload id means, and user group branching probability means for specifying the fraction of resources required by an associated workload which is generated by the corresponding user group.
38. The data structure of claim 37 wherein the fourth entries each include user group entries containing the user group id means, and pointers to the user group probability entries for the corresponding user groups.
39. The data structure of claim 25 wherein selected ones of the physical devices are organized to provide facilitated access between the selected physical devices, and wherein the data structure also comprises a plurality of fifth data entries including means for representing the selected physical devices as entries in an access data structure, means for describing the organization of the selected physical devices, and means for identifying corresponding ones of the first entries.
40. The data structure of claim 39 wherein the first data entries include access structure pointers identifying corresponding ones of the fifth data entries.
41. The data structure of claim 25 further including a model data entry for each model, the model data entries including model id means for identifying the corresponding model, device data structure means for identifying the first data structure, workload data structure means for identifying the second data structure, configuration means for identifying a configuration of the model.
42. The data structure of claim 41 wherein the model data entries also include means for identifying the location on a visual display of elected ones of the devices and workloads of the model.
43. The data structure of claim 41 wherein the model data entries each include means for indicating whether the corresponding model has been modified.
44. A modeling system for facilitating analysis of a computer system, the modeling system comprising:
data structure means for holding physical device information and workload information, both representative of the configuration of the computer system, and metrics information representative of the performance of the computer system, the data structure means including configuration context means for storing the physical device information and the workload information;
change means, coupled to the data structure means, for receiving requests to modify the physical device information, the change means including data structure modification means for transmitting to the data structure means, in response to the received requests, commands to modify the representation of the computer system configuration;
solver means, coupled to the data structure means, for determining values for metrics information for the computer system from the physical device information and the workload information in the data structure means; and user interface means, coupled to the change means and to the data structure means, for providing an interface to a user of the modeling system, the user interface means including means for transmitting to the change means the requests to modify the physical device information made by a user, and means for displaying a diagram of the configuration of the computer system, including values for the metrics information.
data structure means for holding physical device information and workload information, both representative of the configuration of the computer system, and metrics information representative of the performance of the computer system, the data structure means including configuration context means for storing the physical device information and the workload information;
change means, coupled to the data structure means, for receiving requests to modify the physical device information, the change means including data structure modification means for transmitting to the data structure means, in response to the received requests, commands to modify the representation of the computer system configuration;
solver means, coupled to the data structure means, for determining values for metrics information for the computer system from the physical device information and the workload information in the data structure means; and user interface means, coupled to the change means and to the data structure means, for providing an interface to a user of the modeling system, the user interface means including means for transmitting to the change means the requests to modify the physical device information made by a user, and means for displaying a diagram of the configuration of the computer system, including values for the metrics information.
45. The modeling system of claim 44 wherein the data structure means includes display context means for storing display information, and wherein the user interface means includes display logic means for accessing the display context means to obtain the display information.
46. The modeling system of claim 44 wherein the modeling system is coupled to an external storage system for maintaining a copy of data representing the configuration of the computer system, and wherein the modeling system also includes parser means for providing an interface between the external storage system and the physical device information and workload information stored in the data structure means.
47. The modeling system of claim 44 wherein the configuration context means includes metrics means for storing the values for the metrics.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US07/599,221 | 1990-10-17 | ||
US07/599,221 US5276877A (en) | 1990-10-17 | 1990-10-17 | Dynamic computer system performance modeling interface |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2047573A1 true CA2047573A1 (en) | 1992-04-18 |
Family
ID=24398757
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA002047573A Abandoned CA2047573A1 (en) | 1990-10-17 | 1991-07-23 | Dynamic computer system performance modeling interface |
Country Status (6)
Country | Link |
---|---|
US (1) | US5276877A (en) |
JP (1) | JPH04299414A (en) |
CA (1) | CA2047573A1 (en) |
DE (1) | DE4134419A1 (en) |
FR (1) | FR2668271A1 (en) |
GB (1) | GB2250111A (en) |
Families Citing this family (68)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3177999B2 (en) * | 1991-04-25 | 2001-06-18 | カシオ計算機株式会社 | System configuration diagram creation device |
US5537529A (en) * | 1993-04-22 | 1996-07-16 | Apple Computer, Inc. | Apparatus and method for creating versions of computer models and creating communications incorporating created versions therefrom |
JPH07281874A (en) * | 1994-04-15 | 1995-10-27 | Fuji Photo Film Co Ltd | Environment setting system |
JP3636744B2 (en) * | 1994-06-14 | 2005-04-06 | 株式会社日立製作所 | Distributed system and method for creating automatic operation schedule of distributed system |
US5652884A (en) * | 1994-11-14 | 1997-07-29 | Object Technology Licensing Corp. | Method and apparatus for dynamic update of an existing object in an object editor |
US5630131A (en) * | 1994-11-14 | 1997-05-13 | Object Technology Licensing Corp. | Method and apparatus for importing and exporting archive files for a graphical user interface |
US5623598A (en) * | 1994-11-22 | 1997-04-22 | Hewlett-Packard Company | Method for identifying ways to improve performance in computer data storage systems |
US5768586A (en) * | 1995-01-10 | 1998-06-16 | Peoplesoft, Inc. | Net change management for object-oriented modeling |
JPH08314710A (en) * | 1995-05-23 | 1996-11-29 | Chugoku Nippon Denki Software Kk | Support device for construction of computer operating environment |
US6263378B1 (en) * | 1996-06-03 | 2001-07-17 | Sun Microsystems, Inc. | System and method for rapid development of bootstrap device detection modules |
FR2767399B1 (en) * | 1997-08-14 | 1999-09-17 | Bull Sa | METHOD FOR DETERMINING THE START-UP TIME OF A COMPUTER SYSTEM |
US6138122A (en) * | 1998-03-02 | 2000-10-24 | Agilent Technologies | Modeling of internet services |
US7031901B2 (en) * | 1998-05-13 | 2006-04-18 | Abu El Ata Nabil A | System and method for improving predictive modeling of an information system |
US7389211B2 (en) * | 1998-05-13 | 2008-06-17 | Abu El Ata Nabil A | System and method of predictive modeling for managing decisions for business enterprises |
US6990437B1 (en) | 1999-07-02 | 2006-01-24 | Abu El Ata Nabil A | Systems and method for determining performance metrics for constructing information systems |
US6311144B1 (en) | 1998-05-13 | 2001-10-30 | Nabil A. Abu El Ata | Method and apparatus for designing and analyzing information systems using multi-layer mathematical models |
US7783468B2 (en) * | 1998-05-13 | 2010-08-24 | Accretive Technologies, Inc. | Automated system and method for service and cost architecture modeling of enterprise systems |
US20020049573A1 (en) * | 1998-05-13 | 2002-04-25 | El Ata Nabil A. Abu | Automated system and method for designing model based architectures of information systems |
US6748413B1 (en) * | 1999-11-15 | 2004-06-08 | International Business Machines Corporation | Method and apparatus for load balancing of parallel servers in a network environment |
US6957209B1 (en) * | 2000-02-29 | 2005-10-18 | Unisys Corporation | Sizing servers for database management systems via user defined workloads |
US20010051862A1 (en) * | 2000-06-09 | 2001-12-13 | Fujitsu Limited | Simulator, simulation method, and a computer product |
US7881920B2 (en) | 2000-08-29 | 2011-02-01 | Abu El Ata Nabil A | Systemic enterprise management method and apparatus |
US7512894B1 (en) * | 2000-09-11 | 2009-03-31 | International Business Machines Corporation | Pictorial-based user interface management of computer hardware components |
US7003772B2 (en) * | 2000-12-04 | 2006-02-21 | International Business Machines Corporation | Policy management for distributed computing and a method for aging statistics |
US8234229B2 (en) * | 2001-07-27 | 2012-07-31 | International Business Machines Corporation | Method and apparatus for prediction of computer system performance based on types and numbers of active devices |
US6941450B2 (en) * | 2001-07-30 | 2005-09-06 | International Business Machines Corporation | System and method for identifying one or more optimum configurations of a data processing system |
US7043663B1 (en) * | 2001-11-15 | 2006-05-09 | Xiotech Corporation | System and method to monitor and isolate faults in a storage area network |
US20060122845A1 (en) * | 2002-07-31 | 2006-06-08 | Mark Denford | Method and apparatus for the analysis of complex systems |
US7797141B2 (en) * | 2002-10-22 | 2010-09-14 | The Boeing Company | Predictive analysis of availability of systems and/or system components |
US8056046B2 (en) * | 2002-10-22 | 2011-11-08 | The Boeing Company | Integrated system-of-systems modeling environment and related methods |
JP4128516B2 (en) * | 2002-11-18 | 2008-07-30 | 株式会社リコー | Image forming apparatus and program updating method |
US7457864B2 (en) * | 2002-11-27 | 2008-11-25 | International Business Machines Corporation | System and method for managing the performance of a computer system based on operational characteristics of the system components |
JP2004303190A (en) * | 2003-03-20 | 2004-10-28 | Hitachi Ltd | Program, information processor, method for controlling information processor, and recording medium |
GB2406661A (en) * | 2003-09-30 | 2005-04-06 | Toshiba Res Europ Ltd | Configuring a computer apparatus subject to a constraint placed upon the system |
GB2406662A (en) * | 2003-09-30 | 2005-04-06 | Toshiba Res Europ Ltd | Configuring a computer apparatus |
US20050132336A1 (en) * | 2003-12-16 | 2005-06-16 | Intel Corporation | Analyzing software performance data using hierarchical models of software structure |
US20050155032A1 (en) * | 2004-01-12 | 2005-07-14 | Schantz John L. | Dynamic load balancing |
US8782654B2 (en) | 2004-03-13 | 2014-07-15 | Adaptive Computing Enterprises, Inc. | Co-allocating a reservation spanning different compute resources types |
US7971204B2 (en) | 2004-03-13 | 2011-06-28 | Adaptive Computing Enterprises, Inc. | System and method of co-allocating a reservation spanning different compute resources types |
CA2559584A1 (en) | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method of providing a self-optimizing reservation in space of compute resources |
CA2559603A1 (en) | 2004-03-13 | 2005-09-29 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
US7702757B2 (en) | 2004-04-07 | 2010-04-20 | Xiotech Corporation | Method, apparatus and program storage device for providing control to a networked storage architecture |
US20070266388A1 (en) | 2004-06-18 | 2007-11-15 | Cluster Resources, Inc. | System and method for providing advanced reservations in a compute environment |
US8176490B1 (en) | 2004-08-20 | 2012-05-08 | Adaptive Computing Enterprises, Inc. | System and method of interfacing a workload manager and scheduler with an identity manager |
CA2586763C (en) | 2004-11-08 | 2013-12-17 | Cluster Resources, Inc. | System and method of providing system jobs within a compute environment |
US20060161752A1 (en) * | 2005-01-18 | 2006-07-20 | Burkey Todd R | Method, apparatus and program storage device for providing adaptive, attribute driven, closed-loop storage management configuration and control |
US7743380B2 (en) * | 2005-01-21 | 2010-06-22 | Hewlett-Packard Development Company, L.P. | Monitoring clustered software applications |
US7941602B2 (en) * | 2005-02-10 | 2011-05-10 | Xiotech Corporation | Method, apparatus and program storage device for providing geographically isolated failover using instant RAID swapping in mirrored virtual disks |
US8863143B2 (en) | 2006-03-16 | 2014-10-14 | Adaptive Computing Enterprises, Inc. | System and method for managing a hybrid compute environment |
US9075657B2 (en) | 2005-04-07 | 2015-07-07 | Adaptive Computing Enterprises, Inc. | On-demand access to compute resources |
US9231886B2 (en) | 2005-03-16 | 2016-01-05 | Adaptive Computing Enterprises, Inc. | Simple integration of an on-demand compute environment |
US20060218360A1 (en) * | 2005-03-22 | 2006-09-28 | Burkey Todd R | Method, apparatus and program storage device for providing an optimized read methodology for synchronously mirrored virtual disk pairs |
US7702788B2 (en) * | 2005-10-25 | 2010-04-20 | International Business Machines Corporation | Method and apparatus for performance and policy analysis in distributed computing systems |
US20070268308A1 (en) * | 2006-05-17 | 2007-11-22 | Mcmanus Jossie Maite | Method, apparatus, and computer program product for implementing dynamic graphical modeling of computer systems |
US7769843B2 (en) * | 2006-09-22 | 2010-08-03 | Hy Performix, Inc. | Apparatus and method for capacity planning for data center server consolidation and workload reassignment |
US20080109390A1 (en) * | 2006-11-03 | 2008-05-08 | Iszlai Gabriel G | Method for dynamically managing a performance model for a data center |
US8041773B2 (en) | 2007-09-24 | 2011-10-18 | The Research Foundation Of State University Of New York | Automatic clustering for self-organizing grids |
US20090112668A1 (en) * | 2007-10-31 | 2009-04-30 | Abu El Ata Nabil A | Dynamic service emulation of corporate performance |
US8650490B2 (en) * | 2008-03-12 | 2014-02-11 | International Business Machines Corporation | Apparatus and methods for displaying a physical view of a device |
US10678409B2 (en) | 2008-03-12 | 2020-06-09 | International Business Machines Corporation | Displaying an off-switch location |
US7971013B2 (en) * | 2008-04-30 | 2011-06-28 | Xiotech Corporation | Compensating for write speed differences between mirroring storage devices by striping |
US20100011371A1 (en) * | 2008-07-11 | 2010-01-14 | Burkey Todd R | Performance of unary bulk IO operations on virtual disks by interleaving |
US20100011176A1 (en) * | 2008-07-11 | 2010-01-14 | Burkey Todd R | Performance of binary bulk IO operations on virtual disks by interleaving |
US11720290B2 (en) | 2009-10-30 | 2023-08-08 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US10877695B2 (en) | 2009-10-30 | 2020-12-29 | Iii Holdings 2, Llc | Memcached server functionality in a cluster of data processing nodes |
US20130254134A1 (en) * | 2011-09-30 | 2013-09-26 | Dinesh Pothineni | Facet data networks |
US11037253B2 (en) | 2016-04-04 | 2021-06-15 | Hexagon Technology Center Gmbh | Apparatus and method of managing 2D documents for large-scale capital projects |
US9977728B2 (en) * | 2016-06-30 | 2018-05-22 | International Business Machines Corporation | Visual test workload execution modeling |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US4449182A (en) * | 1981-10-05 | 1984-05-15 | Digital Equipment Corporation | Interface between a pair of processors, such as host and peripheral-controlling processors in data processing systems |
US4560985B1 (en) * | 1982-05-07 | 1994-04-12 | Digital Equipment Corp | Dual-count, round-robin ditributed arbitration technique for serial buses |
US4849879A (en) * | 1986-09-02 | 1989-07-18 | Digital Equipment Corp | Data processor performance advisor |
IE872626L (en) * | 1987-09-29 | 1988-04-01 | Smithkline Beckman Corp | Affinity adsorbents for glycopeptide antibiotics. |
EP0372682A3 (en) * | 1988-12-05 | 1991-07-17 | Digital Equipment Corporation | System characterization method |
-
1990
- 1990-10-17 US US07/599,221 patent/US5276877A/en not_active Expired - Lifetime
-
1991
- 1991-07-23 CA CA002047573A patent/CA2047573A1/en not_active Abandoned
- 1991-07-29 GB GB9116310A patent/GB2250111A/en not_active Withdrawn
- 1991-10-16 JP JP3267453A patent/JPH04299414A/en active Pending
- 1991-10-17 FR FR9112840A patent/FR2668271A1/en active Pending
- 1991-10-17 DE DE4134419A patent/DE4134419A1/en not_active Withdrawn
Also Published As
Publication number | Publication date |
---|---|
GB9116310D0 (en) | 1991-09-11 |
GB2250111A (en) | 1992-05-27 |
US5276877A (en) | 1994-01-04 |
DE4134419A1 (en) | 1992-04-30 |
FR2668271A1 (en) | 1992-04-24 |
JPH04299414A (en) | 1992-10-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2047573A1 (en) | Dynamic computer system performance modeling interface | |
US4868763A (en) | Knowledge-based system having plural processors | |
US6275977B1 (en) | Application cooperation method and apparatus | |
US6757000B2 (en) | Object-oriented programming apparatus, object-oriented programming supporting apparatus, component builder apparatus, object-oriented program storage medium, program storage medium for use in object-oriented programming, component storage medium, and object-between-network display method | |
US5613099A (en) | Persistent object storage system with modifiable group skeletal formats | |
US5455952A (en) | Method of computing based on networks of dependent objects | |
US6990652B1 (en) | System and method for determining methods and properties to be invoked on objects in a graphical program | |
CN1860731B (en) | System and method for generating perspectives of a san topology | |
US5907603A (en) | Database-driven automatic message accounting system and method | |
EP0642092A2 (en) | Parallel database system | |
CN100462974C (en) | Apparatus and method for monitoring and debugging query execution objects | |
AU1271601A (en) | Integrated data bank combining system | |
US6772031B1 (en) | Method of, system for, and computer program product for providing a job monitor | |
EP0217922A1 (en) | An array for simulating computer functions for large computer systems. | |
US5864660A (en) | Testing the integration of a plurality of elements in a computer system using a plurality of tests codes, each corresponding to an alternate product configuration for an associated element | |
JP2516703B2 (en) | Logic automatic generation method and logic automatic generation system | |
Molero et al. | A tool for the design and evaluation of fibre channel storage area networks | |
Peng et al. | CAD-integrated engineering-data-management system for spring design | |
Schreiber | Specification and generation of user interfaces with the boss-system | |
Friedman et al. | Windows 2000 performance guide | |
Cherkasova et al. | On scalable net modeling of OLTP | |
JPH06314262A (en) | Distributed processing system | |
US6032176A (en) | Data-independent type computer system: processing machine, data machine and man-machine interface therein | |
ter Hofstede et al. | Specification of Graphic Conventions in Methods | |
Austin et al. | File system caching in large point-to-point networks |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
EEER | Examination request | ||
FZDE | Discontinued |