Review

For a program to run, C1 of its domain must be a meter key to a valid meter {(p1,vmeter)}. While a program runs, Gnosis decrements the three counters in the meter upon which the process depends and each of the meter nodes to which the first meter node is inferior.
When one of these counters goes to zero, the domain executes an implicit jump to the key in slot 2 of that meter node. A node key to the meter is passed. No exit block is used however and no parameters are fetched from the domain. A restart key is produced to the old domain. This restart key is passed to the program on the other side of the meter gate.

METERS may be used for many purposes. Some uses of meters, such as resource monitoring, rather than resource controlling, may be satisfied by creating a meter at the measurement point in the meter hierarchy, installing very large values in each of its three counters, and periodically sampling the counters to determine the change in value over some interval. In such cases there is no need to construct a meter keeper for the meter. {A maximum value of '7FFFFFFFFFFFFF' is equal to 130 years of cpu time, and thus may be assumed to never run out.} However, any meter which may run out of resources must have a meter keeper, or else processes will be lost when the kernel invokes the key in the slot 2 of the meter.

Meters are the only complete way that one program can have the capability of stopping another program or collection of programs. Setting a program's CPU counter to zero stops that program immediately. Meters may be used in this way to regulate the gross rate of resource utilization. This control may be used on time scales from milliseconds to months.

Meter keeper nitty gritties
Because many domains may trap upon the expiration of a single meter, it is necessary to have the meter keeper recognize and compensate for what may appear to be "false" meter traps. If two domains are running under the same meter, and the meter expires, each may experience a meter trap. On the first trap, the meter keeper may put additional resources in the meter and restart the domain that trapped. When that process is completed, the meter keeper will become available, and will immediately receive the second trap, which had been queued while the first one was being processed. The meter keeper may observe that the allegedly empty resource counter (as specified in the trap code) is in fact not empty, and may restart the second domain without the need to add resources to the meter. See (p1,mcs) about a proposed fix to this situation.

Sample meter keeper designs
Many situations arise where a program wishes to have access to the resource utilization information about a domain. In such cases, the domains meter key (in slot 2 of the domain root) is replaced by a meter key to a new fabricated meter, and the program retains the node key to the new meter node, allowing it to interrogate and change resource counters. The fabricated meter contains the original meter key as its superior meter key (in slot 1 of the meter node). Note that it is important to complete the construction of the meter before installing it in the domain, because if anyone tried to call the domain while its meter was invalid, the process represented by the call would vanish without a trace.

DDT

DDT uses meters to stop and start the domains under its control. When a DDT is created for a domain, the DDT creates a meter below the meter which was in slot 2 of the domain root as described above. When DDT wishes to stop the domain, it empties the CPU counter in its dummy meter. Since DDT knows that exactly one domain is running under its meter, and the DDT domain holds a key to the domain, there is no need for a meter keeper, (except perhaps to detect whether the domain was in fact running?)

Command system
The command system creates a meter over itself purely for statistical purposes. The meter is substituted for the command systems meter because the command system needs to be able to interrogate the meter. The meter is initialized to maximum values at the beginning of each session. Periodically, it is sampled to determine how much resource has been consumed over some interval. The meter does not contain a meter keeper.

The command system also creates lower level meters over many of the programs which it loads for its users. These meters are (currently) only used if the user wishes to halt one of its sibling programs. The meter is created with maximum resource values and no meter keeper. If the user requests the meter be emptied, a meter keeper domain is created for the meter. When the meter keeper is invoked, it checks to see if the interrupt is a valid trap or a "false" trap. If the interrupt is valid, the meter keeper calls a NEVER key, leaving itself busy. If the command system wishes to restart whatever processes may be trapped due to the meter being empty, it puts resources back in the meter, and fabricates a restart key to the meter keeper using its domain key. The subsequent "false" entries to the meter keeper are processed by the meter keeper directly to restart all trapped domains.

OS Simulation
The OS simulator uses meters to report cpu usage of a domain to the domain. When a Domain is created under OS simulation, a dummy meter is created, just as with DDT. The resource counters are all set to very large values. The meter keeper happens to be the same domain as the domain keeper for the user domain. The meter keeper key and the domain keeper key have different databytes, allowing the keeper program to recognize which key was activated. Combining the two functions in one domain implicitly solves a series of race condition problems in the OS simulation design. If the user program requests notification after usage of a limited amount of resource, the appropriate counter is adjusted accordingly, which eventually results in a meter trap.

Blip monitor
Several meters can share a meter keeper in the case where a user wishes to monitor several independent programs simultaneously. When any of the programs consumes 2 seconds of cpu time, a meter trap might activate a common meter keeper which might write a character on the users terminal, and reactivate the trapped domain for another 2 second interval. The meter keeper would still have to recognize and ignore false interrupts. It would not be possible to make any assumptions about the ordering of false interrupts with respect to real interrupts from other meters.

Other miscellaneous topics
It might be useful for some meter keepers to stop their domains by making a resource count negative, rather than by zeroing it. This would allow the original value to be restored easily when the domain was restarted, which might be important if someone was using that value for accounting or something.

To the extent that Tymshare and our customers have hierarchical organizations the meter tree will tend to reflect these structures. The customer's meter trees will be grafted onto Tymshare's tree. This will provide for timely information about machine usage by customer, project, etc. It will also provide the opportunity to regulate and limit the use of resources by particular customers. Meters may be administrated by programs so as to provide ample resources at night but restricted resources in the daytime. Since meter readings are always up to date, computer resources may be priced at different rates at different times of the day.

The typical action of the program on the other side of a meter gate might be to make a note of the event {perhaps for charging and producing detailed billing information} and replenishing the balance and restarting the program by means of the restart key. The system of superior meter pointers connects the meters together into a tree. The program that controls a meter node controls all of the programs that depend on that meter and the meters inferior to it.

Meters are used by the scheduler to control the minute to minute resource utilization so as to optimize multiprogramming. See (p3,muxmet) and (p2,supsched).

In applications that involve substantial amounts of computer resources and are done regularly and are associated with the operation of an organization {payroll, for example}, it is advisable to schedule the required resources ahead of time. To this end we propose a program, presumably written by Tymshare, with access to a meter that gives it effective access to the bulk of the computing resources over any span of a few seconds. This program is in a position to grant {for a price} commitments for computer resources during a specified time interval in the future. For this section we call these commitments (_resource contracts) or simply (_contracts). The business end of such a contract would be a meter that can provide the designated resources during the designated interval to any program running with that meter.

The nature of the guarantee is that so long as there is at least one process ready to use the meter during the interval then the designated resources will in fact be delivered. Compliance with this provision is monitored by the contract administrator with the "wait for no process" feature of a meter {(p1,noproc)}. There may be provisions for short periods of time with no process under the contract meter but these would have to be charged for as if there had been some headway. If the contractee {the system using the resources} needed to call other programs for substantial amounts of time it might be arranged that those programs be "certified for use under resource contracts". Prior arrangements at contract time must be made for the use of such programs; such an arrangement would consist of a front end, running under the contract meter, to the certified program. This front end would inform the contract administrator that the contractee was exercising his right to invoke the certified service, and not to penalize for the absence of a process under the meter.

A similar case arises when the contractee wants to use a segment that might have inordinate delays in servicing page faults. The NO_CALL bit of the segment key can be made to mark the beginning of such segment keeper services.

Resource contracts provide the contract administrator with the latitude of when to run the job. This is unacceptable for applications where there is interaction with things outside the control of the computer system such as terminals at the ends of circuits. In such cases the contractee requires a guarantee of a steady stream of computing within some duration of time. The above mechanism can provide this by creating a large number of very short contracts. If 1/3 of the machine were required we could make a sequence of consecutive 15 second contracts each of which would guarantee 5 seconds of resource.

Contracts with short durations would cost more per unit of resource than long contracts for two reasons: The administrator has fewer options of when to provide the resources and someone must pay for the core required to hold the pages until the next commitment begins.

Contracts must be able to require tape drives.

The other use of meters will be by segment nodes {when implemented}. The cost of keeping a collection of pages in core may be shared by designating a meter in a segment node over those pages. This has the effect of paying for pages only once even though several programs are making headway using those pages. Such a key in the segment node causes no CPU resources to be measured by the indicated meter. The main storage counter runs in real time at a rate that is the number of pages under the meter node that are in main storage. While this storage reading will be non reproducible it will presumably be non-chargeable. The right to use such a non-chargeable meter will typically be charged on a flat rate basis.