Accounting Overview

The following contains a brief overview of the philosophy and principles behind MFCF's billing system. To help with one's understanding of the methods involved and the reasons therefor, it presents a general picture without getting into specific details until near the end.

1. Introduction

Some things provide easy ways of determining their cost (the number of pages printed, the number of megabytes of data backed up, etc.), and so MFCF can bill directly for these services with little problem. But for other services, costs do not make themselves so obvious.

Over the last few decades, MFCF has tried various methods of charging for its services. All have had acceptability problems with those members of the faculty that felt overcharged.

Previous attempts have included more socialist systems that taxed users on their ability to pay (e.g. a percentage of their research grants), while others have taken the opposite approach and tried to charge for the exact value received for all CPU and disk usage.

If a machine has very little usage one month and heavy usage the next, it might make sense from a business perspective to charge a lot more money for the second month, since the users received a lot more value from us. Similarly a fast machine will provide more work in less time than a slow machine, so again it might make sense to charge more for CPU time on a fast machine than on a slow one.

But MFCF does not operate as a business; it has a fixed budget. And since our cost of supporting a machine does not vary significantly from one month to the next, nor between a fast and a slow machine, it makes more sense that we should charge about the same amount for the machine each month, regardless of how efficiently its users made use of it.

This latest version of our accounting system more accurately reflects the actual cost of services provided by MFCF. It produces a much more predictable value, both for MFCF and for the machine owners who will know beforehand approximately what they will have to pay and what service they will receive. We hope that it will therefore find more general acceptance among the members of the Faculty.

2. Assumptions

3. Categories of Costs

The ongoing cost of individual pieces of equipment falls into three categories.

3.1 Connection to the Network

The cost of networks has little to do with the actual equipment connected to it. Each additional IP address simply contributes to the ongoing task of such things as keeping track of what equipment connects where, monitoring network traffic, recognizing and responding to problems, and upgrading switches, routers, and cables.

For this reason, MFCF charges a single flat rate for each connection, regardless of the type of equipment.

3.2 Administration of the Equipment

The cost of administering equipment can vary considerably from one type of machine to another. Some equipment simply sits there doing its thing, while other machines require continual human intervention.

Once configured, a thin client for instance requires very little ongoing administration, while a PC running Windows might require considerable time for such things as software installations and upgrades, network problems, and trouble shooting.

But due to economies of scale, even very similar types of equipment can have different administration costs. The users that have chosen to have a particular architecture should pay for the overhead associated with administering it. For instance, given two versions of UNIX running on identical hardware, if dozens of machines run one version while only one or two run the other, each individual machine running the first architecture costs a smaller fraction of the overhead associated with that architecture.

For this reason, MFCF charges administration rates that depend upon the architecture type of each machine, and those rates can change with the general popularity or unpopularity of each architecture.

3.3 Service to the Users of the Equipment

The costs of providing service depends upon the number of users of each machine.

A machine with very few users will generally generate far fewer requests for assistance and require far less problem intervention than a machine with dozens of users.

On the other hand, as a user community increases in size, many users can help others within that community, and many instances of intervention will solve the same problem for several users at the same time.

For these reasons, MFCF charges service rates that depend upon the number of users of a machine, but with sub-linear incremental cost. i.e. a machine with twice the number of users as another machine will cost less than twice as much as the other.

4. Cost Reductions

The way people use or maintain their equipment can affect each of the three costing factors. For instance, some groups may choose to give up some of their freedom of choice or to take on some of the maintenance responsibilities themselves.

The charge reductions to the three factors described below can occur independently and simultaneously. Some machine might even receive all three: have lab designation; operate within a region; and connect to a privately maintained network.

4.1 Network Connections Charge

Users may choose to establish and maintain their own network, thereby reducing the cost to MFCF, and hence reducing our charges.

Generally each such subnetwork will have a connection to the rest of the campus network, so we will charge for at least one IP address per network. (Should the private network ever cause problems for the rest of the campus, we will usually not investigate the cause beyond that connection, which might as a result end up temporarily disabled, with the entire subnetwork losing connectivity with the rest of the world.)

Generally, privately maintained connections should either have all their IP addresses of the form, making them invisible to the rest of the world, or they should comprise a complete easily identifiable subnetwork,

In some special cases, privately maintained connections can have addresses corresponding to other campus networks (but should this arrangement end up causing extra work, they might lose their private status and revert to having normal network connection status).

4.2 Equipment Administration Charge

Some equipment can have a configuration that makes it much easer to administer. Generally such machines will have little or no user-defined state, and their individual unavailability will not seriously affect anyone's ability to do their work. Often it makes no difference who actually uses the machine, and typically even the name of the machine itself does not matter. In such cases, the equipment may receive lab designation, and so have a smaller administration charge.

Machines receiving lab designation do not necessarily have to reside in a large lab setting, and could even function as personal office machines in cases where the user does not mind the inconvenience of such things as limited software and lack of configurability.

Some architectures so obviously deserve the lab designation that they already have their own categories. A thin client provides an extreme example of a lab machine, while a PC configured as a Nexus Windows system qualifies even if used as a personal workstation.

Other situations depend on their own merits. For instance, a Windows PC may mount all user data from elsewhere, and have a configuration that severely limits what software it contains. With several such machines available, when one breaks, a user need only hang an out of order sign on it, notify MFCF, and move to a different machine. Fixing the machine might consist of nothing more than replacing it with another machine loaded with the standard software.

4.3 User Service Charge

Some groups of machines may have very intimate connections with each other and share a large common user community. Adding another similar machine to the group (without increasing the number of users in the community) does incur additional connection and administration costs, but shouldn't significantly increase the user service costs, since the same users will continue doing more or less the same things they would have done, though presumably with a little better response and less conflict. In fact, with the users spread out across more machines, peak loads decline and conflicts due to such problems as memory and swap space occur less often, so the entire region ends up costing less to support.

An XHIER region of UNIX machines forms such a group. They have all mailboxes, passwords, home directories, etc. mounted in common, with users simply choosing one machine over another as the most appropriate or convenient CPU to use at the moment.

Since regions can require less work to service than simply summing the individual machine costs would indicate, the charges must follow some obvious principles:

5. Billing

The method of billing and cost distribution has no effect on the calculation of costs associated with a machine. MFCF provides two billing methods, described below, but these do not preclude other methods should the need arise.

Each piece of equipment has a monthly cost calculated on the principles described in the previous sections. MFCF will either distribute this cost among the sponsors of the machine's users, or bill it directly to the machine's owner.

5.1 Sponsors

Every user of the machine has someone that sponsors their usage. Typically researchers will sponsor themselves and some grad students, MFCF and other administrative departments will sponsor their own staff, and the Dean of Math will sponsor teaching related accounts, including accounts for all students.

The sponsor of each user/sponsor combination on each machine will pay a share of that machine's cost. Since someone that uses twice as much of a resource as another user does not necessarily cost twice as much to support, charges will depend upon a sub-linear proportion of the total cost (currently we use square roots).

MFCF measures the CPU and disk usage on each machine. For machines with non-zero measured usage of both CPU and disk, part of the the cost of the machine will apply to CPU usage and part on disk usage (currently we split 50/50).

5.2 Owners

Some machines will implicitly have a single sponsor for all usage, either because the owner prefers it that way, or because the machine's architecture makes accounting for individual users difficult or impossible.

5.3 Faculty Infrastructure

The Dean pays for some basic infrastructure. For instance, each researcher in the faculty receives their first four IP connections without charge, and each grad student receives a thin client and connection. Researchers that choose to replace the grad student's thin client with other equivalent equipment (e.g. a PC or Mac) may apply an equal amount to the support cost of that equipment.

5.4 Dean's Subsidies

At the discretion of the Dean, subsidies may apply to the amounts charged for various resources. Typically any member of the Math Faculty will receive a 50% subsidy for everything except printing.

5.5 Nuisance Charges

To avoid nickel-and-diming people, individual items that cost less than some small amount (currently $1) and term-bills less than some other small amount (currently $10) receive a 100% subsidy.

6. Implementation — The Monthly Cost of Each Host Machine (H)

As part of the development of this model, MFCF collected data about the time spent supporting various activities and platforms to determine how to apportion costs. Fitting those costs to mathematical functions produced the parameters and damping factors, followed by simplifications such as the use of square-root instead of the observed sub-linear scale value.

6.1 Summary

Each machine will have several associated costs:

The first cost is fixed, while the second is determined by the actual machine and its intended purpose. The user service charge depends on the number and type of users, though not linearly, and also on whether the machine is part of a region.

Note that the total user cost for all machines in a region should add up a value that would be the user cost for a single machine with the same user community. I.e. one machine with 16 CPUs should have the same user service cost as sixteen regional machines with 1 CPU each.

6.2 Parameters

CH = Connection charge (e.g. $9 per IP connection)

DH = Damping factor for multiple users (e.g. 0.8)

AH = Administration charge (e.g. $25.00 for system administration on UNIX)

SH = service charge (e.g. $30.00) for user Support

The damping factor and the administration and service charges depend on the host's architecture, currently with only UNIX machines having a non-zero user service charge. At the moment we do not have active user counts for other architectures, so for those machines, the administration charge effectively includes a user service charge for one user.

6.3 Measured Values

NC = number of network Connections

NH = number of active CPU users on the Host (minimum 1)

NR = number of active CPU users in the Region (minimum 1)

NS = Sum of NHDH over all hosts in the region. (I.e. the sum of the adjusted number of users on each host.)

6.4 The Formula

Cost = {C × NC} + AH + {SH × [NHDH]/NS × NRDH}

Note that computing the sum for all machines in a region of identical architecture will reduce the middle factor in the last term to 1, and the entire region thus has a user service cost that depends upon the number of users in the region but does not depend on the individual usage of machines within that region.

For a typical situation of one host and one connection, this formula reduces to:

Cost = C + AH + { SH × NHDH }

And for a machines with at most one user:

Cost = C + AH +SH

6.5 Example: Three Machines Within And Without A Region

Host Active Users NC NH NHD Individual Charge Region Charge
X W, V, U 1 3 2.41 C + A + S×2.41 C + A + S×(2.41/9.63)×5.28
Y U, T, S, R, Q, P 1 6 4.19 C + A + S×4.19 C + A + S×(4.19/9.63)×5.28
Z V, U, T, S 1 4 3.03 C + A + S×3.03 C + A + S×(3.03/9.63)×5.28

assuming that

DH = .8, AH = A, SH = S.

for all architectures, we have

NR = 8

NRDH = 8.8 = 5.28

NS = 2.41 + 4.19 + 3.03 = 9.63

In the first example, if considered individually the three machines collectively cost:

3×C + 3×A + 9.63×S


In the second example, the region of three machines costs:

3×C + 3×A + 5.28×S


6.6 Future Directions

Eventually MFCF may provide other methods of apportioning costs among machines within a region. In particular, one can rearrange the factors in the user service term to give this:

[ SH × NHDH ]   ×   [ ( NRDH ) / NS ]

which represents the cost of the individual machine and a regional reduction factor.

Note that this regional factor does not depend on the machine under consideration.

Perhaps more realistically, this factor should instead have a separate value for each individual machine and reflect the degree to which that machine contributes to the overall regionality (e.g. how many of its users use how many other machines?). Doing so would also eliminate the glossed-over problem of regions in which machines have different user-service or damping factors.

Whatever happens, the regional factor for any machine would never exceed 1 (otherwise removing the machine from the region would reduce its charges).

7. Implementation — Distributing Costs to Sponsors

If MFCF does not bill the equipment charges for a machine directly to its sponsor, we can distribute the cost to the sponsors of the machine's users (where such information exists).

A machine that has both CPU usage and disk quota will have its cost divided evenly between these two resources. Otherwise the entire cost of the machine will apply to the one resource.

7.1 CPU Usage

Each user of the machine will share the cost in proportion to the square root of their CPU usage. (Thus users with no CPU usage will incur no cost.)

7.2 Disk Usage

Each user of the region (regardless of their CPU usage, if any) will share the cost in proportion to the square root of their disk usage.

Last modified: 2009-May-06 16:18