EMULATOR (SOLVER)

Section: Rutgers DarkLab Tools (1)
Updated: 2006-08-23
Index Return to Main Contents
 

NAME

emulator - temperature server emulator  

SYNOPSIS

emulator <-m file.dot> [-c file.dot] [-h] [-d] [-v] [-w iterations] [-p port] [-f | -l file.log]  

DESCRIPTION

The solver is the part of the suite that actually computes temperatures using finite-element analysis. It receives component utilizations from a trace file or from monitoring daemons. If the utilizations come from a file, i.e. the system is run offline, the end result is another file containing all the usage and temperature information for each component in the system over time. If the utilizations come from the monitoring daemons (each of which running on a different machine than the solver), the applications or system software can query the solver for temperatures. Regardless of where the utilizations come from, the solver computes temperatures at regular intervals; one iteration per second by default. All objects and air regions start the emulation at a user-defined initial air temperature.

This server is the key part of the infrastructure for the temperature emulator suite. It reads a heat and an airflow graph, and then listens to machine usage messages to create a representation of the state in question.

-m file.dot
The machine configuration file to use is a required parameter. It should contain the heat and the airflow graphs of the machine.
-c file.dot
The cluster configuration file to use (optional argument). If it is not present, machine inlet temperatures will remain fixed.
-p port
The port to connect to on the server. Defaults to 8367.
-d
Debug mode. No daemon created on background.
-v
Verbose mode, do not daemonize, and prints messages on screen (silent mode is default).
-b
Prints the emulated temperatures before the air movement. It is a special verbose mode. Do not daemonize.
-l file.log
Log all monitor messages to this file.
-f file.log
Reads utilization and temperature values from a trace file, printing out emulated temperatures.
-w
Number of warm-up iterations.
-h
A brief summary of usage.

 

RULES FOR BUILDING HEATFLOW GRAPHS

A heatflow graph is a data structure in the following basic format:

graph mX {
    graph [quantity=Y,fanspeed=FLOAT,Tinlet=FLOAT]
    componentA1 [T0=FLOAT,label="NAME",mass=FLOAT,kconstant=FLOAT, Q="NAME:(x1,y1)(x2,y2)"];
    componentB1 [T0=FLOAT,label="NAME",mass=FLOAT,kconstant=FLOAT];
    (...)
    /* You should define the air close to the previously defined components  */
    A1_air [T0=FLOAT, kconstant=1004]
    B1_air [T0=FLOAT, kconstant=1004]
    (...)
    /* You can define the downstream air of each component  */
    A1_downstreamair [T0=FLOAT, kconstant=1004]
    B1_downstreamair [T0=FLOAT, kconstant=1004]
    (...)
    /* Example of relationships between components */
    cpu -- cpuair [weight=0.75]
    motherboard -- cpu [weight=0.1]
}

X and Y
The numbers X and Y matter when monitord is being used. In trace-based emulations, both of them should be set to 1. However when using the monitor (online experiments), X and Y together define a range of valid IP addresses, as well as the maximum number of machines that can be monitored, and have their temperatures emulated. That is, assuming one monitor per machine, X is the rightmost byte of the smallest IP address allowed. Y is the absolute difference between X and the rightmost byte of the largest IP address allowed plus one. As a consequence, Y ends up being the maximum number of machines that can be monitored with that configuration. The machines can either have consecutive or sparse addresses, as long as their rightmost bytes fall into that range. For example, our network has 5 hosts:
hostA 192.168.7.5
hostB 192.168.7.6
hostC 192.168.7.7
hostD 192.168.7.8
hostE 192.168.7.9
Suppose that we want to allow the monitoring of any 2 machines in the range hist to hostage. Our configuration should be something like this: graph m6 { graph [quantity=4,fenced=FLOAT,Taint=FLOAT]
That is because 6 is the rightmost byte of the IP address of hostB. Likewise, 4 is the absolute difference between 6 and 9 (the rightmost byte of the IP address if hostE). As a consequence, at most 4 machines in the defined range will be allowed to be monitored.

FLOAT is a floating-point number.

NAME is a character string.

fanspeed is the rate of cubic feet (of air) per minute that the fan imposes to the machine.
Tinlet and T0 are temperature values in Celsius.
mass is the mass of the component in grams.
kconstant is the specific heat capacity of the component.

Q="NAME:(x1,y1)(x2,y2)" is the equation of power vs units of work per time. x1 and x2 are respectively the minimum and the maximum number of units of work per time, that the component named by NAME can do. y1 and y2 are the corresponding power consumed to do that work.

componentA is the name of a basic type of component, whose power curve equation is defined (the name is customizable. i.e.: disk, cpu, motherboard, power etc). componentB: is similar, but its power curve is not defined.

A1_air and B1_air (i.e.: diskair) is the air in direct contact with the component.
A1_downstreamair and B1_downstreamair (i.e.: diskdownstreamair) is the air in contact with the component air. It can be useful to characterize the air movement/circulation.

Finally, the graph definition should contain the heat transfer relationships between components,
and their specific weights. See the example above.

 

RULES FOR BUILDING AIRFLOW GRAPHS

The airflow graph has many similarities with the heatflow graph. This is a model of a very simple machine, with only one cpu and motherboard with memory within the case.

digraph aX {
    graph [quantity=Y,fanspeed=FLOAT,Tinlet=FLOAT]
    inlet [T0=FLOAT, kconstant=1004]
    exhaust [T0=FLOAT, kconstant=1004]

    inlet -> macair [weight=0.9]
    inlet -> cpuair [weight=0.1]

    macair -> exhaust [weight=1]
    cpuair -> exhaust [weight=1]
}

Some particularities of the airflow graph are: (1) It must be a directed acyclic graph (DAG); (2) Only air components defined in the heatflow graph should be referred to in the airflow; (3) inlet and exhaust are compulsory components; (4) The sum of the weights of the out-edges of each component should be exactly equal to 1. There are no restrictions regarding the in-edges. For example, note that the sum of the weights of out-edges of inlet is equal to 1; (5) inlet has no in-edges and exhausthas no out-edges.

 

SEE ALSO

monitord(1); fiddle(1); sensor(1);


 

Index

NAME
SYNOPSIS
DESCRIPTION
RULES FOR BUILDING HEATFLOW GRAPHS
RULES FOR BUILDING AIRFLOW GRAPHS
SEE ALSO

This document was created by man2html using the manual pages.
Time: 03:06:13 GMT, September 04, 2006